Sample Software Security Report for IBM test fire application
Web Application Assessment
for IBM demo Test Fire Website
Parsons Software Security Consulting, LLC
http://www.parsonsisconsulting.com/
http://www.parsonsisconsultingblog.com/
November 22, 2010
Executive Summary
Web Application Assessment Overview
Parsons Software Security Consulting, LLC performed the Web Application Assessment for IBM Test Fire in November of 2010. The Web site assessed was the production environment at http://demo.testfire.net/.
.
Industry leading tools were used to remotely perform the automated portion of the assessment in conjunction with manual analysis and review process. This report documents and prioritizes discovered vulnerabilities.
The application is written in .NET The application uses Java Script and Cascading Style Sheets.
The application is a fake banking application.
Conclusion and Recommendations
We have documented the detailed opportunities to improve the security posture of the application. It is recommended that the High vulnerabilities be addressed as soon as possible (3 months or less). Parsons Software Security Consulting, LLC, is an advisor for your team to utilize to assist in the remediation process.
Proper coding practices using whitelisting, should be instituted. Whitelisting would state that anything that is not specifically allowed is denied. For instance, if a field should only require alphabetic characters, then only those characters should be allowed in that field. This will not only help defend against certain kinds of attacks but also help keep data that is accepted as accurate as possible.
Error handling and trapping should be instituted throughout the application and the server. This will prevent information leakage via error messages resulting from unexpected input from users. Error messages generated should be uniform and uninformative, to prevent them from unintentionally revealing information.
Overview of Web Application Findings
The following Vulnerabilities were discovered:
| Risk Level | Vulnerability Description |
| High | Authentication Bypass SQL injection. An attacker could bypass the login page and login to the application without credentials. |
| High | SQL injection. An attacker could extract sensitive data from the database. |
| High | Blind SQL injection. An attacker could extract sensitive data from the database. |
| High | Cross Site Scripting. An attacker could deface your website or steal customer’s credentials and data. |
| Medium | Database Error Found. Database error found can give information for an attack later on. |
| Medium | Direct Access to Administration Pages. This could reveal highly sensitive information about your website. |
| Medium | Sensitive Files Found. This could reveal highly sensitive information about your website. |
| Low | Cross Site Request Forgery. This could allow an attacker to attack your website via a client. |
| Low | Unencrypted Login Request. This could allow an attacker to steal user’s credentials. |
| Low | Form Auto Complete On. |
Web Application Assessment Details
Assessment Scope
Note: This assessment took place during the month of November, 2010. All vulnerabilities described relate to the site configuration, as it existed at the time, and may or may not be applicable to the current configuration state.
Credentials were used for the assessment.
Findings and Recommendations
The findings below are ordered by risk, with an emphasis on remediation steps to obviate the exposure. Where possible, references are given for hardening and best practices guidelines that apply to the exposure in question.
Vulnerability risk definition is as follows:
High Risk – These findings identify conditions that could directly result in the compromise or unauthorized access of a network, system, application or information.
Medium Risk – These findings identify conditions that do not immediately or directly result in the compromise or unauthorized access of a network, system, application or information, but do provide a capability or information that could, in combination with other capabilities or information, result in the compromise or unauthorized access of a network, system, application or information.
Low Risk – These findings identify conditions that do not immediately or directly result in the compromise of a network, system, application, or information, but do provide information that could be used in combination with other information to gain insight into how to compromise or gain unauthorized access to a network, system, application or information. Low risk findings may also demonstrate an incomplete approach to or application of security measures within the environment.
In many cases issues that were discovered in one location were replicated throughout the application. Thus, the remediation processes may overlap with other discovered vulnerabilities and should be implemented on an application wide basis.
| Vulnerability 1 | Authentication / Weak Authentication |
| Risk | High |
| Reference | http://www.kb.cert.org/vuls/id/466433
See Vimeo Reference http://vimeo.com/17196966 |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
The application has a weak authentication mechanism. As a result, it is possible to bypass the requirement of registering in order to access the literature section of the site. The authentication seems to rely completely on whether or not “username=” is set as part of the “pref” cookie. If any username is set, the user can access the restriction part of the site. The rest of the cookie, including the “password=” portion, is ignored.
Vulnerability Recommendation
The authentication mechanism should check both username and password to verify session validity. Once validity has been established, the session should be connected to a session identifier value to help prevent tampering. Typically, this session ID is stored into a cookie. Subsequently, the session identifier should be checked at each protected page to ensure it is connected with a valid, authenticated session. Only then should the protected page be shown to the user.
Vulnerability Recommendation
This file should be removed from the system. Also, the process of in place backups should be discontinued. This will help ensure sensitive information is not leaked to attackers.
| Vulnerability 2 | Input Validation / SQL Injection |
| Risk | High |
| Reference | |
| Affected URLs | http://demo.testfire.net/
http://demo.testfire.net/bank/account.aspx http://demo.testfire.net/bank/login.aspx http://demo.testfire.net/bank/transaction.aspx |
Vulnerability Description
A potential SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database. Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there.
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.
sSql = “SELECT LocationName FROM Locations “;
sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];
oCmd.CommandText = sSql;
The following example utilizes parameterized queries, and is safe from SQL Injection attacks.
$db = new mysqli(“localhost”, “user”, “pass”, “database”);
$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);
$stmt -> bind_param(“ss”, $user, $pass);
$stmt -> execute();
In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.
The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.
Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.
| Vulnerability 3 | Input Validation / Potential Blind SQL Injection |
| Risk | High |
| Reference | |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
A potential Blind SQL injection vulnerability was identified. This may allow an attacker to gain sensitive information and affect the back end database even though database error messages are not being displayed. Even though no sensitive data was retrieved, it should be ensured that this condition does not exist in code. The symptoms appear to be there. The variable identified is the “uid” variable on the following page:
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
SQL Injection arises from an attacker’s manipulation of query data to modify query logic. The best method of preventing SQL Injection attacks is thereby to separate the logic of a query from its data. This will prevent commands inserted from user input from being executed. The downside of this approach is that it can have an impact on performance, albeit slight, and that each query on the site must be structured in this method for it to be completely effective. If one query is inadvertently bypassed, that could be enough to leave the application vulnerable to SQL Injection. The following code shows a sample SQL statement that is SQL injectable.
sSql = “SELECT LocationName FROM Locations “;
sSql = sSql + ” WHERE LocationID = ” + Request[“LocationID”];
oCmd.CommandText = sSql;
The following example utilizes parameterized queries, and is safe from SQL Injection attacks.
$db = new mysqli(“localhost”, “user”, “pass”, “database”);
$stmt = $db -> prepare(“SELECT priv FROM testUsers WHERE username=? AND password=?”);
$stmt -> bind_param(“ss”, $user, $pass);
$stmt -> execute();
In PHP version 5 and MySQL version 4.1 and above, it is possible to use prepared statements through vendor-specific extensions like mysqli.
The application will send the SQL statement to the server without including the user’s input. Instead, a parameter-?- is used as a placeholder for that input. In this way, user input never becomes part of the command that SQL executes. Any input that an attacker inserts will be effectively negated. An error would still be generated, but it would be a simple data-type conversion error, and not something a hacker could exploit.
Input validation should be happening on all input coming from a user. The vast majority of SQL Injection checks can be prevented by properly validating user input for both type and format. The best method of doing this is via “white listing”. This is defined as only accepting specific account numbers or specific account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. This approach is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.
| Vulnerability 4 | Input Validation / Cross-Site Scripting (XSS) | ||||||||||||||||||||||||
| Risk | High | ||||||||||||||||||||||||
| Reference | http://www.cgisecurity.com/articles/xss-faq.shtml | ||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
Multiple instances of Cross-Site Scripting were identified. This vulnerability could allow an attacker to craft a malicious link or get malicious code inserted in to a user’s browser. Normally this is used to steal session identifiers or credentials allowing them to compromise the application’s data. This vulnerability could also be used to insert malicious content in to the user’s browser potentially compromising their system. The recommendation for this issue should be applied anywhere where the application accepts data from a user and it gets echoed back to the screen. A list of some of the identified URLs with XSS issues are listed in Appendix A. Some of the URLs may have multiple variables that are vulnerable.
The following shows a XSS vulnerability and a popup of document.cookie.
| lang
See Vimeo Reference |
http://demo.testfire.net/bank/customize.aspx
|
Vulnerability Recommendation
Cross-Site Scripting attacks can be avoided by carefully validating all input, and properly encoding all output. Always use as strict a pattern as you can possibly allow. Encoding of output ensures that any scriptable content is properly encoded for HTML before being sent to the client.
Be sure to consider all paths that user input takes through your application. For instance, if data is entered by the user, stored in a database, and then redisplayed later, you must make sure it is properly encoded each time it is retrieved. If you must allow free-format text input, such as in a message board, and you wish to allow some HTML formatting to be used, you can handle this safely by explicitly allowing only a small list of safe tags.
Secure coding practices, sanitization of user input, and properly encoding output should be used. The application should only accept content for which it is expecting for that particular variable. If a variable is only needing to accept alphabetic characters then it should only allow a-z and other characters should be denied. Encoding of the output ensure that any scriptable content is properly encoded for HTML before being sent to the client. This code would properly encode items such as <, >, \, \\, and & with their proper HTML equivalents such as < > " etc.
| Vulnerability 5 | Information Leakage / Verbose Database Error Messages | ||||||||||||||||||||||||||||||||||||
| Risk | High | ||||||||||||||||||||||||||||||||||||
| Reference | http://msdn.microsoft.com/en-us/library/994a1482.aspx | ||||||||||||||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
The database is sending verbose errors to the user’s browser. These errors indicate an unhandled exception by the database server. This information contains sensitive information that an attacker can use to conduct further attacks. It gives an attacker helpful information regarding syntax of requests in which the attacker can use to correct mistakes and increase the effectiveness of attacks.
See Vimeo Reference http://vimeo.com/17196966
Vulnerability Recommendation
The best way to prevent these errors is proper coding techniques in which only proper input is accepted. This should be done in a whitelisting approach. Do not display error messages to the end-user that provide information (such as table names) that could be utilized in orchestrating an attack. Also, there should be definition of the maximum and minimum data lengths for what the application will accept. ODBC error messages should be turned off and raw ODBC and other verbose errors should not be sent to the end user. To remove detailed error messages documentation for the particular database server should be consulted.
| Vulnerability 6 | Admin Directory |
| Risk | Medium |
| Reference | |
| Affected URLs | http://demo.testfire.net/admin/ |
Vulnerability Recommendation
A directory named ‘admin’ was discovered within your web application. Risks associated with an attacker discovering an administrative directory on your application server typically include the potential for the attacker to use the administrative applications to affect the operations of the web site.
| Vulnerability 7 | Information Leakage / Directory Listing/ Sensitive files |
| Risk | Medium |
| Reference | |
| Affected URLs | http://demo.testfire.net/bank/ |
Vulnerability Description
The application has several files that appear to be in place backups of files. These files are sometimes served differently by the web server than files with the standard file extension. In some cases this could lead to information leakage that would give an attacker an idea of how to better attack the system.
See Vimeo Reference http://www.vimeo.com/17200961
Vulnerability Recommendation
These files should be removed from the system and the process of doing in place backups such as this should be discontinued. This will ensure that the server doesn’t accidentally serve sensitive data to an attacker.
| Vulnerability 8 | Cross Site Request Forgery | |||||||||||||||||||||||||||
| Risk | High | |||||||||||||||||||||||||||
| Reference | ||||||||||||||||||||||||||||
| Affected URLs |
|
Vulnerability Description
In order to avoid CSRF attacks, every request should contain a unique identifier, which is a parameter that an attacker cannot guess.
Vulnerability Recommendation
One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie, and if not discard the request. The reason an attacker cannot guess this parameter is the “same origin policy” that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server. Any secret that is hard to guess and is not accessible to an attacker (i.e. not accessible from a different domain) can be used instead of the session id. This will prevent an attacker from crafting a seemingly valid request.
| Vulnerability 9 | Session Handling / Cleartext connections | |||
| Risk | High | |||
| Reference | http://www.kb.cert.org/vuls/id/466433 | |||
| Affected URLs |
|
Vulnerability Description
The application accepts session data over plaintext connections. Sending credentials and data without cryptographic protections could allow for an attacker to intercept this data allowing them to take actions in the intercepted user’s name. Also if cryptographic protections such as TLS/SSL are not used the data being sent or received from the application can be modified. People often use the same password for multiple services. A password intercepted here could allow for its use elsewhere.
Vulnerability Recommendation
The application should use some form of cryptographic protection for credentials and session IDs being sent. This will mitigate the risk of not only the capturing of authentication data but the integrity of data being pulled and submitted to the application as well. Most commonly for web applications this is done with TLS/SSL.
| Vulnerability 10 | Form Auto-complete ON |
| Risk | Low |
| Reference | http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/abbca505-6f63-4267-aac1-1ea89d861eb4.mspx |
| Affected URLs | http://demo.testfire.net/bank/login.aspx |
Vulnerability Description
Most recent browsers have features that will save form field content entered by users and then automatically complete form entry the next time the fields are encountered. This feature is enabled by default and could leak sensitive information since it is stored on the hard drive of the user. The risk of this issue is greatly increased if users are accessing the application from a shared environment.
Vulnerability Recommendation
Recommendations include setting auto complete to “off” on all your forms.
Sources and Further Reading
OWASP: The Open Web Application Security Project
The Web Application Security Consortium
Mark Kruger: The Application Security Pyramid
http://www.coldfusionmuse.com/index.cfm/2006/4/13/security.pyramid.policing
OWASP Top Ten 2007
http://www.owasp.org/index.php/Top_10_2007
OWASP Security Principles
http://www.owasp.org/index.php/Category:Principle
OWASP Common Software Vulnerabilities
http://www.owasp.org/index.php/Category:Vulnerability
Microsoft: Improving Web Application Security
http://msdn2.microsoft.com/en-us/library/ms994921.aspx
Web Application Assessment Points of Contact
For questions or comments regarding this report please contact the following:
| Name | Role | Contact Information |
| Matt Parsons, MSM, CISSP | Vice President, Parsons Software Security Consulting, LLC | mparsons1980@gmail.com
315-559-3588 |
Leave a Reply