Remediation Report for Application Developer (Page 1 of 2)

 Scan Name: webscantest
 Date: 10/24/2017 7:44:45 AM
 Authenticated User: admin
 Total Links / Attackable Links: 475 / 475
 Target URL: https://webscantest.com
http://webscantest.com
 Reports:
<< >>

Summary


Vulnerability Type

Root Causes

Variances

Blind SQL Injection  14   50 
Browser Cache directive (leaking sensitive information)  23   33 
Brute Force Form based Authentication  1   1 
Buffer Overflow  6   14 
Business Logic Abuse  6   10 
Command Injection  1   4 
Content Security Policy Headers  2   2 
Content Type Charset Check  100   139 
Credentials Over Un Encrypted Channel  2   2 
Cross-Site Request Forgery (CSRF)  24   38 
DOM based Cross-site scripting (XSS)  2   2 
Forced Browsing  1   1 
HTTP Response Splitting  1   1 
HTTP User-Agent Check  3   3 
HTTP Verb Tampering  1   2 
HttpOnly attribute  7   7 
Information Leakage  4   4 
Parameter Fuzzing  6   24 
Persistent Cross-site scripting (XSS)  3   7 
Privilege Escalation  1   2 
Reflected Cross-site scripting (XSS)  20   91 
Session Fixation  1   1 
Session Strength  1   2 
Session Upgrade  5   5 
SQL Information Leakage  2   3 
SQL Injection  8   32 
SQL injection Auth Bypass  1   3 
SQL Parameter Check  1   1 
XPath Injection  3   11 
Total:  250   495 

By Risk

Variances: 495

Details by Module

   Disable Validate Applet

Collapse Blind SQL Injection

Confidence
Severity
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 / 4 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_double_by_name.php Root Cause #4: (Parameter: name / 4 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_get_by_id.php Root Cause #5: (Parameter: id / 4 Attack Variances)  Expand
URL: http://webscantest.com/datastore/search_get_by_name.php Root Cause #6: (Parameter: name / 4 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)

Confidence
Severity
some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/cors.php Root Cause #15: (1 Attack Variance)  Expand
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

Confidence
Severity
some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/business/privilege.php Root Cause #45: (Parameter: admin / 2 Attack Variances)  Expand
URL: http://webscantest.com/business/account.php Root Cause #46: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/product.php Root Cause #47: (Parameter: id / 2 Attack Variances)  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.


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:  

Obfuscate the transaction data and validate pricing with back end processing.


Collapse Content Security Policy Headers

Confidence
Severity
some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/business Root Cause #52: (1 Attack Variance)  Expand

Description:  

The Content Security Policy hasn’t been declared either through the meta-tag or the header, so the browser's trust of the content received from the server can be exploited. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.


Recommendations:  

The new Content-Security-Policy HTTP response header helps you reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header. CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that the browser should consider to be valid sources of executable scripts. A CSP compatible browser will then only execute scripts loaded in source files received from those whitelisted domains, ignoring all other script (including inline scripts and event-handling HTML attributes).


Collapse Content Type Charset Check

Confidence
Severity
some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/ Root Cause #55: (2 Attack Variances)  Expand
URL: http://webscantest.com/bjax/ Root Cause #56: (1 Attack Variance)  Expand
URL: http://webscantest.com/bjax/ajax.js Root Cause #57: (1 Attack Variance)  Expand
URL: http://webscantest.com/business Root Cause #58: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/ Root Cause #59: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/access.php Root Cause #60: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/account.php Root Cause #61: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/privilege.php Root Cause #62: (1 Attack Variance)  Expand
URL: http://webscantest.com/business/quantity.php Root Cause #63: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors.php Root Cause #64: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_private.php Root Cause #65: (1 Attack Variance)  Expand
URL: http://webscantest.com/cors_public.php Root Cause #66: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/ Root Cause #67: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/aboutyou.php Root Cause #68: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #69: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/blockedbyns.php Root Cause #70: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem.php Root Cause #71: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/checkitem_lookup.php Root Cause #72: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/checkitem_result.php Root Cause #73: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/dom.php Root Cause #74: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/index.php Root Cause #75: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/linkout.php Root Cause #76: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/product.php Root Cause #77: (4 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/products.php Root Cause #78: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/request.php Root Cause #79: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation.php Root Cause #80: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_history.php Root Cause #81: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_receipt.php Root Cause #82: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/reservation_submit.php Root Cause #83: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/review.php Root Cause #84: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/sample.php Root Cause #85: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/search.php Root Cause #86: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/sitereviews.php Root Cause #87: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf Root Cause #88: (1 Attack Variance)  Expand
URL: http://webscantest.com/csrf/ Root Cause #89: (1 Attack Variance)  Expand
URL: http://webscantest.com/csrf/csrfpost.php Root Cause #90: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/redirect.php Root Cause #91: (3 Attack Variances)  Expand
URL: http://webscantest.com/csrf/session.php Root Cause #92: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/token.php Root Cause #93: (2 Attack Variances)  Expand
URL: http://webscantest.com/css/style.css Root Cause #94: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/ Root Cause #95: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_id.php Root Cause #96: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_name.php Root Cause #97: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_statement.php Root Cause #98: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_statement_index.php Root Cause #99: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_double_by_name.php Root Cause #100: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_get_by_id.php Root Cause #101: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_get_by_name.php Root Cause #102: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_single_by_name.php Root Cause #103: (1 Attack Variance)  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)

Confidence
Severity
some text
  Collapse Site: http://webscantest.com:80
URL: http://webscantest.com/bjax/servertime.php Root Cause #156: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/aboutyou.php Root Cause #157: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/aboutyou2.php Root Cause #158: (1 Attack Variance)  Expand
URL: http://webscantest.com/crosstraining/request.php Root Cause #159: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/review.php Root Cause #160: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/search.php Root Cause #161: (2 Attack Variances)  Expand
URL: http://webscantest.com/crosstraining/sitereviews.php Root Cause #162: (2 Attack Variances)  Expand
URL: http://webscantest.com/csrf/csrfpost.php Root Cause #163: (1 Attack Variance)  Expand
URL: http://webscantest.com/csrf/token.php Root Cause #164: (1 Attack Variance)  Expand
URL: http://webscantest.com/datastore/search_by_id.php Root Cause #165: (2 Attack Variances)  Expand