Remediation Report for Application Developer (Page 1 of 3)

 Scan Name: Webscantest-includeAPIs-reactjs
 Date: 8/24/2016 11:24:23 PM
 Authenticated User: testuser
 Total Links / Attackable Links: 416 / 416
 Target URL: http://webscantest.com
 Reports:
<< >>

Summary


Vulnerability Type

Root Causes

Variances

Blind SQL Injection  15   48 
Browser Cache directive (leaking sensitive information)  20   31 
Brute Force Form based Authentication  1   1 
Buffer Overflow  6   10 
Business Logic Abuse  5   5 
Command Injection  1   4 
Content Type Charset Check  100   153 
Cross-Site Request Forgery (CSRF)  25   50 
Custom Passive Check  10   10 
DOM based Cross-site scripting (XSS)  1   1 
HTTP Verb Tampering  1   2 
HttpOnly attribute  5   7 
Information Leakage  4   4 
Parameter Fuzzing  6   16 
Persistent Cross-site scripting (XSS)  2   6 
Reflected Cross-site scripting (XSS)  20   141 
Session Fixation  1   1 
Session Strength  1   1 
SQL Information Leakage  5   7 
SQL Injection  9   36 
SQL injection Auth Bypass  1   3 
SQL Parameter Check  1   1 
XPath Injection  3   11 
Total:  243   549 

By Risk

Variances: 549

Details by Module

   Disable Validate Applet

Collapse Blind SQL Injection

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/datastore/getimage_by_id.php Root Cause #1: (Parameter: id / 4 Attack Variances)  Expand
URL: http://webscantest.com/datastore/getimage_by_name.php Root Cause #2: (Parameter: name / 3 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_by_name.php Root Cause #3: (Parameter: name / 3 Attack Variances)  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 database errors should 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:  

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input.

Primary Defenses:

  • Use of Prepared Statements (Parameterized Queries)

    Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied. Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker.

  • Use of Stored Procedures

    Stored procedures have the same effect as the use of prepared statements when implemented safely* which is the norm for most stored procedure languages. They require the developer to just build SQL statements with parameters which are automatically parameterized unless the developer does something largely out of the norm. The difference between prepared statements and stored procedures is that the SQL code for a stored procedure is defined and stored in the database itself, and then called from the application. Both of these techniques have the same effectiveness in preventing SQL injection so your organization should choose which approach makes the most sense for you.

  • Escaping all User Supplied Input

    This technique is to escape user input before putting it in a query. However, this methodology is frail compared to using parameterized queries and we cannot guarantee it will prevent all SQL Injection in all situations. This technique should only be used, with caution, to retrofit legacy code in a cost effective way. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries.

    Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities. Full details on ESAPI are available at OWASP.

Additional Defenses:
  • Least Privilege

    To minimize the potential damage of a successful SQL injection attack, you should minimize the privileges assigned to every database account in your environment. Do not assign DBA or admin type access rights to your application accounts. We understand that this is easy, and everything just ‘works’ when you do it this way, but it is very dangerous. Start from the ground up to determine what access rights your application accounts require, rather than trying to figure out what access rights you need to take away. Make sure that accounts that only need read access are only granted read access to the tables they need access to. If an account only needs access to portions of a table, consider creating a view that limits access to that portion of the data and assigning the account access to the view instead, rather than the underlying table. Rarely, if ever, grant create or delete access to database accounts.

  • White List Input Validation

    Input validation can be used to detect unauthorized input before it is passed to the SQL query. For more information please see the OWASP Input Validation Cheat Sheet. Proceed with caution here. Validated data is not necessarily safe to insert into SQL queries via string building.


Collapse Browser Cache directive (leaking sensitive information)

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/cors_private.php Root Cause #16: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_public.php Root Cause #17: (1 Attack Variance)  Expand
URL: http://webscantest.com/css/ Root Cause #18: (4 Attack Variances)  Expand

Description:  

The response browser cache headers allow response caching. If the response contains sensitive information then it may be leaked into the browser cache.

By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Finally, unless specifically constrained by a cache-control directive, a caching system MAY always store a successful response as a cache entry, MAY return it without validation if it is fresh, and MAY return it after successful validation. If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time. Therefore, the browser has a capability to temporarily store some of the pages browsed. These cached files are stored in a folder. When we ask for these pages again, the browser displays them from its cache. Logging out from an application obviously does not clear the browser cache of any sensitive information that might have been stored.


Recommendations:  

Update Cache-Control http header to include no-store directive. The purpose of this directive is to prevent the inadvertent release or retention of sensitive information. The suggested HTTP response headers are:
Cache-Control: no-cache, no-store
Expires: 0
Pragma: no-cache


Collapse Business Logic Abuse

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/business/privilege.php Root Cause #43: (Parameter: admin / 1 Attack Variance)  Expand
URL: http://webscantest.com/business/account.php Root Cause #44: (1 Attack Variance)  Expand

Description:  

Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than it is intended? Or, perhaps, users are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently, these business logic checks simply are not present in the application.
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic and pay huge dividends. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to complete destruction of the application. (Note that this was a real world application penetration test, so complete destruction was not actually carried out but a proof of concept was done instead).


Recommendations:  

Limit the degree of escalation. Do not permit a user to gain extra privilege after successful authentication, because the user is already authorized to hold some privilege


Description:  

Business logic can have security flaws that allow a user to do something that isn't allowed by the business. For example, if there is a limit on reimbursement of $1000, could an attacker misuse the system to request more money than it is intended? Or, perhaps, users are supposed to do operations in a particular order, but an attacker could invoke them out of sequence. Or can a user make a purchase for a negative amount of money? Frequently, these business logic checks simply are not present in the application.
Automated tools find it hard to understand context, hence it's up to a person to perform these kinds of tests. The following two examples will illustrate how understanding the functionality of the application, the developer's intentions, and some creative "out-of-the-box" thinking can break the application's logic and pay huge dividends. The first example starts with a simplistic parameter manipulation, whereas the second is a real world example of a multi-step process leading to complete destruction of the application. (Note that this was a real world application penetration test, so complete destruction was not actually carried out but a proof of concept was done instead).


Recommendations:  

Setup generic response for error conditions. The error page should not disclose information about the success or failure of a sensitive operation. For instance, the login page should not confirm that the login is correct and the password incorrect.


Collapse Content Type Charset Check

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/ Root Cause #49: (2 Attack Variances)  Expand
URL: http://webscantest.com/bjax/ Root Cause #50: (1 Attack Variance)  Expand
URL: http://webscantest.com/bjax/ajax.js Root Cause #51: (1 Attack Variance)  Expand
URL: http://webscantest.com/business Root Cause #52: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/ Root Cause #53: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/access.php Root Cause #54: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/account.php Root Cause #55: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/privilege.php Root Cause #56: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/quantity.php Root Cause #57: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors.php Root Cause #58: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_private.php Root Cause #59: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_public.php Root Cause #60: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/ Root Cause #61: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/aboutyou.php Root Cause #62: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #63: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/blockedbyns.php Root Cause #64: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem.php Root Cause #65: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem_lookup.php Root Cause #66: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem_result.php Root Cause #67: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/dom.php Root Cause #68: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/index.php Root Cause #69: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/linkout.php Root Cause #70: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/product.php Root Cause #71: (4 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/products.php Root Cause #72: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/request.php Root Cause #73: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/reservation.php Root Cause #74: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_history.php Root Cause #75: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_receipt.php Root Cause #76: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_submit.php Root Cause #77: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/review.php Root Cause #78: (4 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/sample.php Root Cause #79: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/search.php Root Cause #80: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/sitereviews.php Root Cause #81: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf Root Cause #82: (1 Attack Variance)  Expand
URL: http://webscantest.com/csrf/ Root Cause #83: (1 Attack Variance)  Expand
URL: http://webscantest.com/csrf/csrfpost.php Root Cause #84: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/redirect.php Root Cause #85: (3 Attack Variances)  Expand
URL: http://webscantest.com/csrf/session.php Root Cause #86: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/token.php Root Cause #87: (2 Attack Variances)  Expand
URL: http://webscantest.com/css/style.css Root Cause #88: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/ Root Cause #89: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_id.php Root Cause #90: (2 Attack Variances)  Expand

Description:  

The encoding hasn’t been declared either through the meta-tag, the byte-order-mark or the header, so the browser will make an attempt to detect the document’s encoding. This exploit only works if the document reflects user input and the browser can be tricked into encoding the page as UTF-7 instead of UTF-8. Some of the browsers actually support UTF-7.


Recommendations:  

Always declare the encoding of your document. Use the HTTP header if you can. Always use an in-document declaration too.
You can use @charset or HTTP headers to declare the encoding of your style sheet, but you only need to do so if your style sheet contains non-ASCII characters and, for some reason, you can't rely on the encoding of the HTML and the associated style sheet to be the same.
Try to avoid using the byte-order mark in UTF-8, and ensure that your HTML code is saved in Unicode normalization form C (NFC).


Collapse Cross-Site Request Forgery (CSRF)

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/bjax/servertime.php Root Cause #149: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou.php Root Cause #150: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #151: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/request.php Root Cause #152: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/review.php Root Cause #153: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/search.php Root Cause #154: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/sitereviews.php Root Cause #155: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/csrfpost.php Root Cause #156: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/token.php Root Cause #157: (2 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_by_id.php Root Cause #158: (2 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_by_name.php Root Cause #159: (2 Attack Variances)  Expand

Description:  

Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.
For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.
Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.
Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.


Recommendations:  

Web sites have various CSRF countermeasures available:

  • Requiring a secret, user-specific token in all form submissions and side-effect URLs prevents CSRF; the attacker's site cannot put the right token in its submissions
  • Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
  • Limiting the lifetime of session cookies
  • Checking the HTTP Referer header
  • Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
  • Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies

An easy and effective solution is to use a CSRF filter such as OWASP's CSRFGuard. The filter intercepts responses, detects if it is a html document and inserts a token in to the forms and optionally inserts script to insert tokens in ajax functions. The filter also intercepts requests to check that the token is present.


Collapse Custom Passive Check

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/crosstraining/product.php Root Cause #174: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/products.php Root Cause #175: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/review.php Root Cause #176: (1 Attack Variance)  Expand

Description:  

The description for the Example Passive Attack.


Recommendations:  

Refer to your web server's documentation for instructions.


Collapse DOM based Cross-site scripting (XSS)

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/crosstraining/sample.php Root Cause #187: (1 Attack Variance)  Expand

Description:  

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it to lead to execution of injected code. This document will only discuss JavaScript bugs which lead to XSS.

The DOM, or Document Object Model, is the structural format that may be used to represent documents in the browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie. The DOM is also used by the browser for security - for example to limit scripts on different domains obtaining session cookies for other domains. A DOM-based cross site scripting vulnerability may occur when active content, such as a JavaScript function, is modified by a specially crafted request such that a DOM element that can be controlled by an attacker.

There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.


Recommendations:  

Not all XSS bugs require the attacker to control the content returned from the server, but can instead abuse poor JavaScript coding practices to achieve the same results. The consequences are the same as a typical XSS flaw, only the means of delivery is different.

In comparison to other cross site scripting vulnerabilities (reflected and stored XSS), where an unsanitized parameter is passed by the server, returned to the user and executed in the context of the user's browser, a DOM based cross site scripting vulnerability controls the flow of the code by using elements of the Document Object Model (DOM) along with code crafted by the attacker to change the flow.

Due to their nature, DOM based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may result in many of the general XSS filtering and detection rules impotent against such attacks.
The consequences of DOM based cross site scripting flaws are as wide ranging as those seen in more well known forms of XSS, including cookie retrieval, further malicious script injection, etc. and should therefore be treated with the same severity as such.


Collapse HTTP Verb Tampering

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/crosstraining/review.php Root Cause #188: (2 Attack Variances)  Expand

Description:  

A page which is expecting only POST requests, is requested by HTTP method GET.

This attack module sends a GET request to a page which has only been used for POSTs.
HTTP Verb tampering is generally used in conjunction with syntactic and semantic attacks as way to bypass certain defense measures.
When an application does not properly handle user supplied data, an attacker can supply content to a web application, typically via a parameter value, that is reflected back to the user.
By requesting the link with a modified http verb, the page renders the parameter values.
Recommendations:  

Some resources may allow both GET and POST methods e.g. an edit form may be hyperlinked using a parameter value defining the record to be edited, but the form is submitted by POST to itself. Users may bookmark a page that is the result of a POST and return to it at a later date.

To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it’s expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don’t allow attackers to add arbitrary name/value pairs.


Collapse HttpOnly attribute

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/crosstraining/request.php Root Cause #189: (1 Attack Variance)  Expand

Description:  

The HttpOnly attribute directs browsers to use cookies via the HTTP protocol only. An HttpOnly cookie is not accessible via non-HTTP methods, such as calls via JavaScript (e.g., referencing "document.cookie"), and therefore cannot be stolen easily via cross-site scripting (a pervasive attack technique).


Recommendations:  

If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.


Collapse Information Leakage

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/cors_private.php Root Cause #194: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_public.php Root Cause #195: (1 Attack Variance)  Expand

Description:  

Revealing system data or debugging information helps an adversary learn about the system and form a plan of attack. An information leak occurs when system data or debugging information leaves the program through an output stream or logging function.


Recommendations:  

Depending upon the system configuration, this information can be dumped to a console, written to a log file, or exposed to a remote user. In some cases the error message tells the attacker precisely what sort of an attack the system will be vulnerable to.
For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.
In the example above, the search path could imply information about the type of operating system, the applications installed on the system, and the amount of care that the administrators have put into configuring the program.


Collapse Persistent Cross-site scripting (XSS)

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/crosstraining/request.php Root Cause #204: (Parameter: fname / 5 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/reservation_history.php Root Cause #205: (1 Attack Variance)  Expand


Description:  

Persistent Cross-site Scripting (XSS) is the attack that is loaded with the vulnerable web application. The attack is originated by the victim loading the offending URI.


Recommendations:  

  • Filter all information sent to the server via form POST/GET and URL query parameters with a particular emphasis on filtering out HTML-specific characters.
  • Escape the escape characters, which attackers can use to neutralize your attempts to be safe. Use a security-focused encoding library to make sure these rules are properly implemented
  • Never insert untrusted data into your HTML document
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side.


Description:  

Persistent XSS attacks are those where the injected script is permanently stored in database, message forum, visitor log, or other trusted data store. The victim then retrieves the malicious script from the server when it requests the stored information. For example, the attacker might inject XSS into a log message, which might not be handled properly when an administrator views the logs.


Recommendations:  

  • Filter all information sent to the client with a particular emphasis on filtering out HTML-specific characters.
  • Understand the context in which your data will be used and the encoding that will be expected.
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side.


Collapse Reflected Cross-site scripting (XSS)

some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/bjax/servertime.php Root Cause #208: (Parameter: msg / 8 Attack Variances)  Expand
URL: http://webscantest.com/business/account.php Root Cause #209: (Parameter: accountId / 8 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/ Root Cause #210: (Parameter: Referer / 4 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou.php Root Cause #211: (Parameter: fname / 8 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #212: (Parameter: fname / 8 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #213: (Parameter: nick / 8 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #214: (Parameter: returnto / 8 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/blockedbyns.php Root Cause #215: (Parameter: Comment / 2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem_lookup.php Root Cause #216: (Parameter: q / 8 Attack Variances)  Expand