Site Report

 Scan Name: scanme-local
 Date: 5/22/2008 5:19:48 PM
 Authenticated User: (none)
 Total Links / Attackable Links: 142 / 93
 Target URL: http://192.168.1.2/vulnsite
 

    Site: http://192.168.1.2:80 (192.168.1.2)

    Apache/2.0.x (39+)

Vulnerabilities

Vulnerabilities by Risk

Vulnerabilities by Who Will Fix

Vulnerability Trend

Remediation Report for Application Developer

Vulnerability Type

Root Causes

Vulnerabilities
Blind SQL  1   1 
Cross Site Scripting  6   72 
SQL Injection  11   75 
CMD Injection  4   16 
Parameter Analysis  6   18 
Session Strength  1   1 
Java Grinder  2   2 
Total:  31   185 

By Risk

Vulnerabilities: 185

Details


Collapse Blind SQL
some text
http://192.168.1.2:80/vulnsite/shutterdb/item.php 1 parameter / 1 vuln   Expand


Description:   These SQL injection techniques analyze the application's response to parameter values that are designed to be interpreted and executed by a database. These requests contain arguments that are not affected by input validation filters. The application submits the original payload to the database, where the database interprets the payload as a valid SQL query. This implies that arbitrary SQL commands may be executed through this parameter value. These tests do not generate database errors, nor should database errors appear in the HTML response.
Vulnerabilities identified by this module highlight problems with input validation routines and the creation of SQL queries. They should be addressed by the fundamental approaches taken to counter common SQL injection exploits.
Recommendations:   Several techniques can be used to block database injection attacks. These techniques complement each other and address security at different points in the application. The impact of a SQL injection attack is minimized by implementing multiple defense measures.
  • Normalize all user-supplied data before applying filters, regular expressions, or submitting the data to a database. This means that all URL-encoded (%xx), HTML-encoded (&#xx;), or other encoding schemes should be reduced to the internal character representation expected by the application. This prevents attackers from using alternate encoding schemes to bypass filters.
  • Implement positive filters that examine user-supplied data for expected characters. Define data types for user-supplied values and ensure that submitted data match these types, such as numeric or date. String or text values should be carefully matched to a limited subset of characters such as alpha, numeric, spaces, or certain punctuation characters as necessary. If any value received by the application contains an unexpected character, then it should be rejected.
  • Negative filtering can also prevent attacks, but may be more unreliable or more difficult to implement for language sets that require non-ASCII characters. Examine all data received from the web browser for SQL syntax characters. If any of these characters are present, then they should be escaped or removed. The single quote (') or double quote (") are often used to envelope parameters in a SQL query. Other malicious characters include the asterisk, semi-colon, dash (minus sign), and parentheses. These characters could be used to prematurely end a query statement.
  • Avoid string concatenation for SQL query construction. String concatenation, where the query is created programmatically by appending values together, makes an injection attack easier to accomplish because the syntax of the query can be easily disrupted by malicious characters.
  • SQL statements should use pre-defined views, parameterized functions, or stored procedures to query the database. These techniques do not enable the content of a parameter to affect the structure of a SQL statement. Even if a parameter contains malicious characters, then the function will always return an error due to incorrect values.
  • Store user-supplied values with appropriate data types within the database. For example, dates should be stored as DATE types (if available) instead of a VARCHAR string.


Collapse Cross Site Scripting
some text
http://192.168.1.2:80/vulnsite/crosstraining/reviews.php 4 parameters / 39 vulns   Expand

some text
http://192.168.1.2:80/vulnsite/crosstraining/allprofiles.php 2 parameters / 33 vulns   Expand


Description:   The application does not filter text or other data for potentially malicious HTML content. This enables an attacker to craft arbitrary HTML content. This vulnerability typically requires that an attacker be able to submit JavaScript <script> tags as part of a field that is re-displayed to one or more users. The <script> tag contains instructions that are executed in a user's web browser, not on the web application server. JavaScript functions can be used to write raw HTML, read cookie values, pull JavaScript code from a third-party web server, or send data to a third-party web server.

Consequently, a user could cause arbitrary HTML such as JavaScript tags to be displayed to other users. Usually, an attacker will attempt to manipulate an XSS vulnerability in order to present malicious HTML as if it came from a legitimate source. This attack is often combined with a social engineering attack that attempts to trick users into divulging their passwords, financial, or personal information.
Recommendations:   Cross-site scripting and HTML injection attacks can be defeated by applying robust input validation filters for all data received from the web browser. Strong countermeasures include:
  • Do not permit users to include HTML content in posts, notes, or other data that will be displayed by the application.
  • If users are permitted to include HTML entities, then limit access to specific elements or attributes.
    • Formatting elements such as <b>, <i>, and <u> should be checked to ensure they only contain the expected character (b, i, or u).
    • Elements such as <a ...> and <img ...> should only permit the href or src attribute to be modified. Check the content of these attributes to ensure that dynamic code (JavaScript, VBscript, etc.) has not been inserted.
    • Use validation filters that match allowed, expected items and reject all unmatched items. Do not attempt to use validation filters that reject known malicious strings because they can often be bypassed by alternate character encoding. The validation filter should deny all HTML entities by default.
  • Use output filters to strip malicious tags or convert angle brackets to their HTML-encoded equivalent.
  • Use the programming language's built-in routines to remove potentially malicious characters.
    • The PHP htmlentities() function prevents potentially malicious HTML characters from being passed through variables. The following example demonstrates how to protect a parameter (screen) from HTML injection:
      $screen_safe = htmlentities($_REQUEST["screen"]);


Collapse SQL Injection
some text
http://192.168.1.2:80/vulnsite/datastore/single_get_link.php 1 parameter / 2 vulns   Expand

some text
http://192.168.1.2:80/vulnsite/datastore/double_get_link.php 1 parameter / 2 vulns   Expand

some text
http://192.168.1.2:80/vulnsite/payment_analysis/test_get.php 3 parameters / 30 vulns   Expand