TechnicalInfoBannerA
TechnicalInfoBannerB
TechnicalInfoBannerC

Whitepapers

  Application Assessment Questioning
What should a consultant be looking for when conducting an application assessment?

Custom Application Assessment

Application security assessment is a unique area of assessment and penetration testing.  Unlike infrastructure based assessments, the methodology utilised by a security professional for identifying security vulnerabilities and significant issues is highly dependant upon the type of application being assessed.

Although several high-level methodologies do exist (and some guides can indeed be quite comprehensive), they are often not generic or versatile enough to cope with the wide variety of custom applications commonly encountered.  Many methodologies used by professional security assessment organisations are in fact highly guarded.

In general, the applications are normally subjected to the following groups of tests:

  • Inspection of application validation and bounds checking for both accidental and mischievous input.
  • Manipulation of client-side code and locally stored information such as session information and configuration files.
  • Examination of application-to-application interaction between system components such as the web service and back-end data sources.
  • Discovery of opportunities that could be utilised by an attacker to escalate their permissions
  • Examination of event logging functionality.
  • Examination of authentication methods in use for their robustness and resilience to various subversion techniques.

Regardless of whether it is a web-enabled client-server application or an n-tier compiled application, the methodology actually implemented by the security consultant to assess the security of all client-side functionality will also be subject to the consultants own experience and skill set.

Instead of focusing on an all-encompassing application security assessment methodology, many consultants may find it more practical to cycle through a check-list of questions.  The emphasis of the questions is not so much on how you test the application, but more as to what the consultant should be looking for.

Experience Matters

The tables below, list the types of questions commonly thought of or actually asked when assessing a custom application.  These questions will aid a consultant in ensuring that all areas of an application have been covered, but the results will always unique to the custom development and the experience of the consultant to interpret the answers into valuable (non-cryptic) advice for the application owner.

For practical use, the questions have been divided into the following groupings:

  • Authentication Processes
  • Event Logging
  • Data Validation and Manipulation
  • Client Installation
  • Cryptography

Authentication Processes

Step

Y/N/?

Does the application support client authentication? 
Is client authentication user unique or shared? 
Is authentication solely based upon client host access permissions? 
Is the authentication process logged at both client and server hosts? 
Does the application require hierarchical access levels? 
How many credentials are required to authenticate? 
Does the application respond with non-informative authentication failure messages? 
Are their multiple tiers to the authentication process? 
Does the authentication process reveal information about the authenticating device? 
Are confidential authentication details displayed on screen while the client user is typing them in? 
Does the application respond appropriately to missing credentials? 
Is authentication information encrypted when sent over the network? 
Is authentication information stored on the client host? 
Is it possible to uniquely identify the previous user of the client from cached information? 
Is there any kind of user lockout procedure? 
Is there any kind of host lockout procedure? 
How does the application inform the client of account lockout? 
Is it technically possible to automatically DoS the applications multiple user accounts? 
Is it technically possible to brute-force authentication procedures and user accounts? 
Can multiple clients be authenticated and access the application at the same time? 
Is there any client timeout after a period of inactivity? 
Is this timeout appropriate to the application? 
Does the timeout cancel the current authenticated session? 
Does the timeout cancel all other simultaneous authenticated sessions? 
Can the client initiate a logout procedure? 
Does client logout cancel all other active sessions? 
Does any kind of refresh or caching allow logged out users to reuse the application without again supplying their authentication details? 
Is it possible to forcibly disable the authenticated client upon server-side revocation of credentials? 
Can the client continue operation after revocation? 
How are authentication details originally supplied to the client user? 
Is it possible to guess other client users credential details from a known set of credentials? 
Is it possible to change authentication details after authenticating to the application? 
Is it possible to reuse old passwords? 
Are there any complexity rules for ensuring strong passwords? 
Are confidential authentication details shown in plain text on the screen during the process of changing them? 
Is the previous password required to verify any changes to a new suite of authentication details? 
Are authentication detail changes logged? 
Is there a secure process for the client to change their own password or authentication details? 

For web-based applications, the author recommends the following papers:
Web Based Session Management

Custom HTML Authentication

Event Logging

Step

Y/N/?

Is the authentication process logged at both client and server hosts? 
Are authentication detail changes logged? 
Are software failures and errors logged on the Server? 
Are software failures and errors logged on the Client? 
Is it possible to retrieve confidential authentication information from these logs? 
Is it possible to uniquely identify both client host and user from these logs? 
Is it possible to review these logs from within the application? 
Are permissions restrictive enough to prevent inappropriate access to the logs? 
What level of information is logged by the application? (e.g. Read/Write access, modification of data, copy/paste data) 
Are log files time sequential, and can they positively identify the time of the action? 
Is there any validation of event logs, and can missing/deleted entries be discovered or recovered? 
Are various levels of event logging related to access permission levels? 
How long do log entries exist for? 
What method of backup and recovery of event logs exist? 

Data Validation & Manipulation

Step

Y/N/?

Do the primary client application input areas provide client-side checking? 
Do the primary client application input areas provide server-side checking? 
Are content input areas restrictive to appropriate data types? (e.g. Numeric fields for currency input) 
How does the application behave when rejecting bad input data? 
Does the client application only accept known valid data? 
Does the application sanitize bad data? 
Does the application redisplay bad data with error information? 
Can bad data error information reveal internal application workings? 
Is it possible to overflow data input areas? 
Does the application falter on very large data input variables? 
Does the application gracefully cancel the client users current connection on bad data input? 
Is it possible to generate errors from backend processes due to un-sanitized input? (e.g. SQL insertion problems with databases) 
Does the application support multiple input formats? (e.g. Unicode representations) 
Does the application support extended characters and handle them gracefully? (e.g. NUL byte injection) 
Can input data be obfuscated and used to carry attack payloads? (e.g. alternative IP representations) 
Is the client application communication encrypted or otherwise obfuscated? 
Is it conceptually possible to hijack the applications communication channel? 
Is it possible to DoS intra-application component communications? 
Are debug options available? 

For web-based applications, the author recommends the following technical papers:
URL Embedded Attacks
HTML Code Injection and Cross-site Scripting

Client Installation

Step

Y/N/?

Are client application components validated before installation? 
Are there access permissions to installed application components that will stop manipulation? 
Is it possible to patch or otherwise update the application while clients are using it? 
Is there an uninstall function? 
Does the application rely upon any third-party developed components? (e.g. ActiveX DLL libraries) 
Is there any kind of version control to application connectivity? 
Is it possible to have multiple client installations on the same host? 
Are checksums or MD5 hashes available for verifying the integrity of the application components? 
Is there a client installation log per host? 
Are customisable and configuration files stored locally in a secure way? 
Is cached content or transfer files stored locally in a secure way? 

Cryptography

Step

Y/N/?

Are known cryptographic techniques used to encrypt local data storage? 
Are known cryptographic techniques used to encrypt intra-application component communications? 
Is it possible to select or force the level of cryptography to an insecure level? 
If a custom cryptographic method is implemented, is it using industry acceptable levels of encryption? 
Is the cryptographic technique appropriate to the application and method of communication? 
Is client authentication handled by digital certificates? 
If digital certificates are used, can they be transported between hosts? 
     
    Copyright 2001-2007 © Gunter Ollmann