parsonsisconsulting

Parsons Software Security Consulting Blog

Sample Software Security Report for IBM test fire application

leave a comment »

Web Application Assessment

for IBM demo Test Fire Website

http://demo.testfire.net/

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

http://demo.testfire.net/bank/transfer.aspx

http://demo.testfire.net/subscribe.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
lang

See Vimeo Reference

http://demo.testfire.net/bank/customize.aspx

 

http://www.vimeo.com/17200635

uid http://demo.testfire.net/bank/login.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
name http://demo.testfire.net/comment.aspx
comment.aspx http://demo.testfire.net/comment.aspx
txtSearch http://demo.testfire.net/search.aspx
txtEmail http://demo.testfire.net/subscribe.aspx

 

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

 

http://www.vimeo.com/17200635

 

 

 

 

 

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 &lt; &gt; &quot; etc.

 

 

Vulnerability 5 Information Leakage / Verbose Database Error Messages
Risk High
Reference http://msdn.microsoft.com/en-us/library/994a1482.aspx
Affected URLs
amUserId http://demo.testfire.net/
listAccounts http://demo.testfire.net/bank/account.aspx
uid http://demo.testfire.net/bank/login.aspx
passw http://demo.testfire.net/bank/login.aspx
login.aspx http://demo.testfire.net/bank/login.aspx
before http://demo.testfire.net/bank/transaction.aspx
after http://demo.testfire.net/bank/transaction.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
debitAccount http://demo.testfire.net/bank/transfer.aspx
creditAccount http://demo.testfire.net/bank/transfer.aspx
txtEmail http://demo.testfire.net/subscribe.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

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/

http://demo.testfire.net/pr/

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
admin.aspx http://demo.testfire.net/admin/admin.aspx
account.aspx http://demo.testfire.net/bank/account.aspx
apply.aspx http://demo.testfire.net/bank/apply.aspx
customize.aspx http://demo.testfire.net/bank/customize.aspx
logout.aspx http://demo.testfire.net/bank/logout.aspx
transaction.aspx http://demo.testfire.net/bank/transaction.aspx
transfer.aspx http://demo.testfire.net/bank/transfer.aspx
comment.aspx http://demo.testfire.net/comment.aspx
subscribe.aspx http://demo.testfire.net/subscribe.aspx

 

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
http://demo.testfire.net/bank/customize.aspx
http://demo.testfire.net/bank/queryxpath.aspx
http://demo.testfire.net/bank/transaction.aspx

 

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

http://www.owasp.org

 

The Web Application Security Consortium

http://www.webappsec.org

 

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

 

 

 

Written by mparsons1980

November 29, 2010 at 4:18 pm

Posted in Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: