Checking Your Web Application

To check for broken links:

To check Cascading Style Sheets (CSS):

To check for exposed directory structure:

  • Nikto (one of the many server vulnerabilities Nikto can discover)
  • Wikto

To check for SQL Injection vulnerabilities:

To check for Cross-site scripting (XSS) vulnerabilities:

Cross-site scripting (XSS) is a client attack. If a web application accepts text (such as the following) into a field and (by presenting the entered data to the client) produces an alert on the client, then the web application can be used to attack the client.

alert("Vulnerable to XSS");

Typical reflected XSS example: a URL containing a script. The script does not reside on the server.

Typical stored XSS example: script included in data entered or uploaded. The script does reside on the server.

A more interesting attack would be an iframe which opens a link to an untrustworthy web page. The assumption that the web application is making: data entered into this field is the data I am expecting to see (also referred to as “valid data”).

The demo version allows you to scan any web site, operated by you, for Cross Site Scripting Vulnerabilities. Acunetix WVS will report the vulnerabilities’ location and will suggest techniques to fix them. Note that this edition does not allow saving of the reports.

The demo version you can also test all aspects of the product (including scanning for SQL Injection, Google hacking, and directory traversal attacks) against these Acunetix test sites:
http://testphp.acunetix.com
http://testasp.acunetix.com
http://testaspnet.acunetix.com

Host user-uploaded content on a separate domain (e.g. usercontent.example.com). Any script in the user-uploaded content won’t have access to content in your application domain.

  • DOMinator is Firefox-based software for analysis and identification of DOM based Cross Site Scripting issues (DOMXss or “type-0 XSS”). (blog)

To check for Cross-Site Request Forgery:

Cross-Site Request Forgery (CSRF) is a client attack tricking a user into submitting a request. Tricking a person into clicking a link while they are logged into an application (such as electronic banking) and thereby submitting an unintended (“forged”) request would be an example of a CSRF attack. The assumption that the web application is making: the transaction was submitted by the application user, and not by a third party which is riding the application user’s session. Same origin policy enforcement at the client side would prevent CSRF attacks, but the web application cannot assume that same origin policy is enforced. A CSRF attack can be difficult to prevent. You must inspect the business logic, and not simply scan for input. You can expect any “Are you sure?” measures, which are intended to alert the user when an unintended server interaction is suspected, to be ineffective. You can expect the user to choose the “Yes” option without reading the text. More elaborate measures (such as Captcha codes) will slow down the user in hopes of more informed decisions. The OWASP CSRFGuard Project attempts to address the issue of request integrity through the use of unique request tokens. See also PaulDotCom Episode 214 for Cross Site Request Forgery scanning with Pinata. (Something known as MonkeyFist is also intended to help discovery CSRF vulnerabilities.) See Michael Brooks’ DEFCON presentation “CSRF Bouncing” [pdf].

To check for Cross-site tracing (XST):

If a Web server supports the TRACE method, an attacker can craft a special HTTP request that bounces malicious scripts into a victim’s browser, resulting in an XST attack. You do not need the TRACE method in production environments.

  • Either disable or block the TRACE method.
  • In Apache, use mod_rewrite.
  • In IIS, use UrlScan.

To check for JavaScript errors:

By default, Internet Explore does not notify the user about JavaScript errors. When testing your own web site, choose ‘Internet Options’ on the Advanced tab. Uncheck ‘Disable script debugging’.

To check for SWF errors:

  • Review Flash applications with HP’s SwfScan (functionality is in HP’s WebInspect).
  • See the blog from Peleus Uhley of Adobe regarding Creating more secure SWF web applications. Updated to include changes made in Flash Player 10.
  • IBM has a site (demo.testfire.net/vulnerable.swf) which illustrates Flash vulnerabilities (Cross-Site Flashing Examples); read IBM’s Flash Parameter Injection whitepaper and HP’s Blinded by Flash Solving the widespread security risks Flash developers currently can’t see that threaten enterprise data.
  • FlashFirebug – Debug ANY AS3 SWF files on the web. Edit properties and inspect elements. Redirect SWF output to the extension. Run AS3 code and transform objects on the fly. Access SWF assets with the decompiler. View AMF calls and Shared Objects and much more!

The role and limitations of automated testing

Automation can be used to identify vulnerabilities of the following Technical Attack types:

  • Command Execution
  • Buffer Overflow
  • Format String Attack
  • LDAP Injection
  • OS Commanding
  • SQL Injection
  • SSI Injection
  • XPathInjection
  • Information Disclosure
  • Directory Indexing
  • Information Leakage
  • Path Traversal
  • Predictable Resource Location
  • Client-Side
  • Content Spoofing
  • Cross-site Scripting
  • HTTP Response Splitting

You will need people to identify the following non-technical, business logic vulnerabilities:

  • Authentication
  • Brute Force
  • Insufficient Authentication
  • Weak Password Recovery Validation
  • Cross-site Request Forgery (CSRF)
  • Authorization
  • Credential/Session Prediction
  • Insufficient Authorization
  • Insufficient Session Expiration
  • Session Fixation
  • Logical Attacks
  • Abuse of Functionality
  • Denial of Service
  • Insufficient Anti-automation
  • Insufficient Process Validation

  1. ADAST – automated testing
    1. Web Hacking Tools
      1. App Spider
      2. App Scan
      3. Web Inspect
      4. Acunetix
  2. Manual testing
    1. BURP Suite
    2. ZAP (Zed Attack Proxy)

This entry was posted on Saturday, December 23rd, 2017 at 4:52 PM and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

Comments are closed.