New scanning engine with improved vulnerability detection AND verification makes finding and fixing security issues in web applications easier.

London, 1st September 2010 – Acunetix, a market leader in web application security scanning technology, today announced version 7 of its popular Web Vulnerability Scanner. With the new human like vulnerability verifying techniques, revolutionary scanning engine and support for a wider variety of web applications, Acunetix re-establishes its technology lead in web application security. Acunetix WVS Version 7 also features improved performance, less false positives and detection of a wide range of new web vulnerability types.

“With Acunetix WVS v7 we focused on finding more vulnerabilities, reducing false positives, and on improving scanner performance,” said Robert Abela, Acunetix Technical Manager. “As a result, Acunetix 7 is now 300% faster, can reduce false positives up to 50% and detects new vulnerabilities such as stored directory traversal.  This helps businesses reduce the time and resources needed to secure their web applications significantly.”

Unique vulnerability verifying technique reduces false positives
Acunetix v7 includes new advanced vulnerability verifying techniques which result in much less false positives, and thus saves time of security administrators trying to reproduce such situations.  Such accuracy is achieved by sending a number of test inputs to the web application, and depending on the response, Acunetix v7 will automatically determine which web vulnerability checks to launch against the web application.

New faster scanning engine reduces time to scan a website by up to 300%
Acunetix WVS Version 7 includes a new fast multi-threaded scanner that can scan on more threads at a time and more efficiently. Scans that could take hours to complete now can be done in minutes, depending on website structure and web applications.

Acunetix 7 reduces time needed to fix security vulnerabilities
When a web security threat is discovered, Acunetix WVS Version 7 presents the developers with a more precise and understandable technical and vulnerability remediation information, to help them fix the issue in a much shorter time.  To improve understanding, different variants of the vulnerability are gathered in one detailed vulnerability report. Acunetix v7 can also re-check a fix for a particular vulnerability, without having to rescan the entire website.

Detect more web vulnerabilities
Thanks to the new revolutionary scanning engine and website crawler, Version 7 is able to find much more vulnerabilities than ever before.  The new site crawler’s in-depth analysis of the website presentation layer discovers more website parameters and inputs. Acunetix 7 is therefore capable of finding many more vulnerabilities in a larger variety of different web applications.

Scan a wider range of web applications
Acunetix v7 is also able to crawl and scan a wider variety of web technologies. Support for Web 2.0 applications has been improved, and also session handling.  All of the advanced penetration testing tools have been rewritten to support Web 2.0 requests, such as JSON, XML and more.

HTTP authentication
Acunetix WVS v7 now supports more than a single pair of HTTP credentials for the same host.  Thanks to the new HTTP authentication settings node, one can pre-define credentials per host, directory and even file.

Easily create your own vulnerability checks
Acunetix v7 now has improved support for creating custom vulnerability checks. Vulnerability checks are written in JavaScript, the most popular scripting language with web developers, and can thus be easily adjusted or extended.  A scripting tool and SDK are also available to assist developers in writing custom web vulnerability and security checks.

Lower cost subscription licenses
Subscription based licenses now also include the maintenance agreement and are thus significantly cheaper. In addition free support and free version upgrades are included.

Other Features

• New graphical scan status interface shows more information about a web scan in progress
• Avoid the lengthy process of manually analyzing the code by specifying the label or tag instead of actual parameter name
• Verify that AcuSensor Technology is correctly installed with a simple click of a button
• During a scan, less bandwidth is consumed and less stress is put on the server thanks to improved network traffic handling
• A number of new network security checks have been added and other ones improved.

Acunetix WVS Trial Edition
Download Acunetix Web Vulnerability Scanner v7 trial edition from here

About Acunetix
Acunetix is a market leader in web application security technology. Founded in 2004, Acunetix customers include the US Army, US Airforce, AT&T, KPMG, Telstra, Fujitsu, Adidas and many more.   For more information please visit: http://www.acunetix.com.

Click here to watch the high quality version of this video

Improvements:

• Improved HTTP Fuzzer tool; added Response Word count (extract raw text {remove tags} from HTML response and count the words) and Raw Text view.  This feature is useful for comparing responses.
• Improved Blind SQL injection timing script; it will automatically probe the current response time from server. This information will be used during execution. This improvement will reduce false positives.  We’ve also adjusted this script to reduce some non-timing related false positives.

Bug Fixes:

• Fixed: Scanner crashing in module tm_web_applications.dll when multiple scans were running at the same time
• Fixed: If V 7 is activated on the same machine where v6.5 is installed, it will deactivated.  Now they no longer de-activate each other
• Fixed: When installing a new build from the Update tool, wvs.exe remained in memory and it had to be manually terminated.

How to upgrade to build 20100825:

On starting up Acunetix WVS, a pop up window will automatically notify you that a more recent build is available for download.  To download the
latest build, navigate to General > Program Updates node in the Tools explorer, and click on Download and Install new build.

Testing Acunetix WVS Version 7 RC1:

If you are interested in testing the Release Candidate build of Version 7, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.

Contact us on support@acunetix.com for any technical queries, and on sales@acunetix.com for any sales queries.

• Improved Cross-Site scripting (XSS) vulnerabilities detection scripts
• Improved blind SQLl injection vulnerability checks to reduce false positives
• Added a good number of new Cold Fusion security checks (including the latest directory traversal)
• Added a number new Apache Tomcat checks
• Improved File Upload security checks scripts

Bug Fix:

Fixed: HTTP Proxy crashing while manual browsing some particular websites

How to upgrade to build 20100818:

On starting up Acunetix WVS, a pop up window will automatically notify you that a more recent build is available for download.  To download the
latest build, navigate to General > Program Updates node in the Tools explorer, and click on Download and Install new build.

Testing Acunetix WVS Version 7 Beta:

If you are interested in testing the BETA of Version 7, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.

Contact us on support@acunetix.com for any technical queries, and on sales@acunetix.com for any sales queries.

• *.script – The actual vulnerability check written in JavaScript.  Such scripts are stored in the ‘\Data\Scripts\’ sub directory in the Acunetix WVS installation directory.
• *.xml – This file contains all the documentation related to the vulnerability description, such as vulnerability details, remediation, severity level and other details.  These XML files use VulnXML format and are stored in the ‘\Data\Scripts\XML’ sub directory in the Acunetix WVS installation directory.

Creating a new vulnerability check

1. Writing the Vulnerability check script

To write a new vulnerability check script, you can use any text editor of your choice, or else WVS Scripting tool which is available for free.

The tool and detailed Acunetix WVS scripting reference can be downloaded from the following URL; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.  We recommend you use our tool since it is specifically designed to assist you in writing Acunetix WVS Vulnerability Checks.  It also includes a number of functions to help you test your scripts.

2. Writing the vulnerability XML file (VulnXML format)

To create a new XML file using VulnXML format, use Acunetix WVS Vulnerability Editor which is available from the Acunetix WVS Program Group.

Follow the below procedure to create a new VulnXML file for a custom vulnerability check;

1. Right Click the VulnXML node and select ‘Add Vulnerability’.
2. Specify the VulnXML filename and also specify if you want to use the default template.
3. Specify all the required details to populate the VulnXML vulnerability file.  For a detailed description of all fields available refer to the following list;
   1. Name -The name of the vulnerability (e.g., could be the same as the name given to the VulnXML file.)
   2. Version – Test Version number
   3. Released – Date when Test/Vulnerability was created (yyyy/mm/dd)
   4. Updated - Date of last time this Vulnerability was updated (yyyy/mm/dd)
   5. Severity - Defines the vulnerability level e.g. high severity indicates that if this test generates failures, the target being scanned has a severe vulnerability
   6. Alert – Defines if the alert is to be triggered on success or failure of the test
   7. Type – Select the type of vulnerability from the drop down menu, e.g. parameter manipulation, canonicalization etc
   8. Affects - Defines which components of the target is affected by such vulnerability, e.g. server, directory etc
   9. Description – This field should contain a description of the vulnerability
   10. Impact – This field should contain information on the impact generated if such vulnerability is exploited
   11. Recommendation – This field should contain a number of recommendations to help the developer eliminate the reported vulnerability
   12. Detailed Information – This field should contain a detailed technical description of the reported vulnerability
   13. Tags – tags related to the vulnerability.

In the ‘References’ tab you can specify links to additional information about the vulnerability (e.g., cause and related fix).  You can add additional references by right clicking and selecting ‘Add reference’.

1. Database - Specify the Link heading/title of the article/information
2. URL – Contains the URL.

Modifying Vulnerability check

Note: The built-in vulnerability checks cannot be modified.  Onlly their VulnXML files (vulnerability details) can be modified.

Modifying a custom vulnerability check

To modify a custom vulnerability check, open the script in the WVS Scripting tool and proceed with the desired changed.  The WVS Scripting tool and detailed scripting reference are available from; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.

Modifying the vulnerability VulnXML file

To modify an existing vulnerability check, open Acunetix Vulnerability Editor and select the script to edit from the VulnXML node.  Click on the section which you would like to edit and proceed with the text changes.  Once ready click on the ‘Save’ icon (first icon) in the top left corner or the Vulnerability Editor.

It has been one long year of development, testing and late nights at the office, though it was all worth it, and the results speak for themselves!  Most of the core components have been rewritten, such as the crawler, scanner, vulnerability checks and the HTTP stack.  Acunetix WVS Version 7 is around 75% faster and more intelligent scanner than its predecessors.  Most of the web vulnerability checks have been migrated from VulnXML format to Scripts.  This allows us to have more advanced and flexible security checks, while reducing false positives.  It is also easier for you to develop your own web vulnerability checks.  Version 7 also includes much more meticulous web security tests, some of which were not possible before.

If you are interested in testing the new BETA of Version 7, and you already own an Acunetix WVS Enterprise or Consultant license with a valid maintenance agreement, contact us at beta@acunetix.com.

The FREE version of Acunetix WVS Version 7 BETA can be downloaded from here

The new features of Version 7 are:

• A new revolutionary and intelligent scanning engine
  • Detection of a wide range of new web vulnerability types
  • No more ‘brute force style’ vulnerability checks
  • Consumes less bandwidth
• Less False Positives and False Negatives reported
  • Website parameters are thoroughly analyzed to understand their purpose
  • A Number of thorough checks are launched before vulnerabilities are reported
  • Human like vulnerability verifying techniques
• Scriptable Vulnerabilities
  • More flexible and advanced web security checks
  • Easier to script own vulnerabilities
  • Faster processing
• Consolidation of reported vulnerabilities
  • Different variants of the same vulnerability are consolidated under one detailed report
  • Presenting the problem to developers in a more precise and understandable way
  • Facilitates prioritization and coordination of vulnerability remediation
• Advanced analysis of website presentation layer
  • Less chances of breaking down a website because of a security scan
  • Ability to automatically submit the correct data in web forms
• A whole variety of new vulnerability checks
  • Stored SQL injection
  • Stored File Inclusion
  • Stored Directory Traversal
  • Stored Code Execution
  • Stored File Tampering
  • More advanced WebDav auditing checks
  • Automated form based authentication auditing (e.g. tests to check if credentials can be brute forced, for common username and passwords etc)
  • Test for SQL Injection In URI
• New Scan Status Interface
  • Graphical presentation of scan status
  • Granular explanation of current running tasks
  • Ability to capture more information at a glance
• Re-Scan capabilities
  • Right click a reported vulnerability and relaunch the test
  • No need to rerun a whole crawl and scan to verify fixes
  • Saves time in verifying corrections
• Ability to specify label or tag instead of actual parameter name in input fields settings node
• Option to automatically randomize input for parameters specified in Input Fields settings node
• New well known web applications (e.g. WordPress) finger printing module

Major improvements in Version 7:

• Drastically improved Web 2.0 applications support
  • Better handling and parsing of JSON and XML requests and responses, and other similar Web 2.0 technologies
• Improved Session Management
• Improved HTTP Sniffer / Manual crawling process
  • Support for a wider variety of content-types
  • Support for Web 2.0 requests and responses e.g. JSON, XML etc
• Improved network traffic handling
  • Support for HTTP Keep-alive
  • DNS Caching helps in reducing multiple DNS requests
  • Ability to control delay between requests
  • Faster handling of traffic
• HTTP Authentication
  • Support for Digest HTTP authentication mechanism
  • Crawler supports more than a single pair of HTTP credentials for the same host
  • HTTP Authentication settings are now shared between all Acunetix WVS tools
  • Granular specification of credentials (per server, directory or file)
    New HTTP Authentication settings node
• Site Crawler
  • Supports a wider variety of communication mechanisms
  • Improved handling and detection of links and input parameters
  • Faster crawling of websites
• Improved XSS Detection rate
• Improved web server security auditing techniques for source code disclosure, directory listing and directory traversal checks
• Drastically improved file upload security checks
• Improved DNS auditing scripts
• Improved security checks for old, backup files and other similar file checks

Acunetix VWS Version 7 documentation

The Acunetix WVS Version 7 user manual is available in PDF Format and also in HTML Format.

With the introduction of scripting, a Getting Started guide / SDK is available to help you understand how the new vulnerability checks are implemented in Acunetix WVS, and to help you write your own scripts / security checks.  We also developed a new tool, ‘WVS Scripting’, to help you writing your own scripts and testing them.  You can download the documentation and tool from the following location; http://www.acunetix.com/download/tools/Acunetix_SDK.zip.

At a later stage, a more detailed SDK and ‘WVS Scripting’ tool documentation will also be released.

1. Configure the web browser

Configure your web browser of choice to proxy all the traffic through the Acunetix WVS HTTP Sniffer tool, as shown in the above screen shot.  Presuming that the web browser is running on the same machine where Acunetix WVS is installed, set the proxy server IP to 127.0.0.1 and the proxy server port to 8080.

2. Start the HTTP Sniffer and start browsing the website using the configured web browser.

3. Once ready, stop the HTTP sniffer. Save captured data by selecting ‘Save Logs’ from the Actions drop down menu.

4. Import Logs to Crawler

In the Site Crawler node, click the ‘Build Structure from HTTP Sniffer log’ button (highlighted in the above screen shot) to import the captured data into the Site Crawler.

5. Save the crawler import results by selecting ‘Save Results’ from the Actions drop down menu.

6. Launch the Scan

Click on the New Scan button to launch the scan wizard.  In the first step of the Scan Wizard select the option ‘Scan using saved crawling results’ as highlighted in the above screen shot.  Proceed with completing the scan wizard to launch the automated scan against the manually browsed website.

Note: Only the links you’ve manually crawled will be automatically scanned.  Other pages in the website, even those linked from manually crawled pages will not be crawled or scanned.

Editing a HTTP Request

1. From a Scan or crawl, right click a file and select ‘Edit with HTTP Editor’.

2. From the HTTP Editor Toolbar, the following options can be edited:

• Method – Select one of the standard HTTP methods such as GET, POST and HEAD.  You can also specify a custom method by typing it in the ‘Method’ input field, such as OPTIONS, TRACE or DELETE.
• Protocol – Select the HTTP Protocol (HTTP/1.0 or HTTP/1.1) version to be used for the request.
• URL – Specify the URL, including the hostname of target object that you want to request (e.g. http://192.168.0.28/). You can specify a relative URL without hostname and request the hostname via the request headers.

3. The Request tab shows the headers of the HTTP request. You can edit any of the headers by specifying the Header name e.g. Cookie or User-Agent and assigning the header value associated to it, e.g. ID=1.

4. To craft a HTTP request with request data apart from the headers (e.g. a POST request with variables), enter the data in the ‘Request Data’ window. Variables’ data can also be edited by the Variable Editor.

The Variable Editor can be launched by clicking on the ‘Edit query Variables’ button. Query variables are separated from the URL by a “?” and are encoded in the URL-Encode standard. With the variable editor you can edit query variables, cookies and other request data. You can add, remove, URL-encode and URL-decode variables using the buttons in the small toolbar at the bottom of the variable editor window. Click ‘OK’ to store the changes and close the Variable Editor.

You can supply data other than the URL encoded variables, such as XML documents for PROPFIND request. Specify the content length and the content type through the appropriate (‘content length’ and ‘content type’) headers. In the case that no content length or type is specified, the HTTP Editor will use “application/x-www-form-urlencoded” as the default content type, whilst the content length is automatically calculated.

5. Use the toolbar at the top of the request page to add and remove request headers, add cookie variables, open the encoder-decoder tool and to toggle between HTTP and HTTPS.

6. Click the ‘Encoder Tool’ button   to encode-decode any text data that you want to send with a HTTP request or that you got back in response. This tool makes use of Base64 and URL-encoding techniques to convert plain text data to send in a request. Click ‘Start’ to request to URL.

Note: For websites with AcuSensor Technology enabled, you can manually add AcuSensor Technology headers to the HTTP request. To do this, right click the ‘Request Headers’ window pane and select ‘Add AcuSensor headers’.  If AcuSensor Technology is enabled, you can view specific AcuSensor Technology related data in the response tab ‘AcuSensor Data’.

Text Only Tab

This tab displays the request in plain text. You can make changes to the request by editing the text directly on display.

Analyzing HTTP Responses

After the HTTP request is sent to the web server, the server response in the bottom pane of the HTTP Editor can be analyzed. The server response is shown in the tabs ‘Response headers’, ‘Response data’, ‘View Page’, and ‘HTML structure analysis’.

Response Tabs

Once a HTTP response is received from the target server, you can analyze the request details using the response tabs below:

• Response Headers – Displays HTTP response headers.
• Response Data – Displays the HTTP response data received from the web server (similar to web browsers’ option view source).
• View Page – Displays the web page without relevant images or CSS.  Clicking on any of the links will display the request of that link in the ‘Request Headers’ tab and will update the URL in the HTTP Editor toolbar.
• HTML Structure Analyses – Displays a list of links, commencts, client scripts, web forms and META tages found in the HTTP response.
• AcuSensor Data – Displays a list of AcuSensor Technology parameters if AcuSensor headers are added in the HTTP request and AcuSensor is Enabled.

Testing HTTP Authentication

HTTP authentication is part of the HTTP specification. If a site performs HTTP authentication, then the browser will display a username and password pop-up dialog. With HTTP authentication, the web server validates the logon against a database of users (with IIS these are local Windows user accounts and with Apache these are stored in a file).

Testing the Username and Password Strength for HTTP Authentication

1. the target URL e.g. www.test.com/login/ in the ‘Target URL to test’ edit box and select ‘HTTP’ as the authentication method to be used for the attack.

2. The default dictionaries will be used.  You can also specify your own Username and Password dictionaries by specifying the full path to a plain text file containing the list of usernames or passwords to attempt to login with.  Click ‘Start’ to start the Authentication tester.

Note: By default the Authentication tester will classify a failed logon if the server returns a HTTP response value of 401.  However, if custom failed login page is used, a matching string or regular expression must be specified in the ‘Logon has failed if’ field.

Testing form based authentication

A login sequence that uses web forms authentication asks for the username and password via a web form, which is then validated on the server via a custom script, rather than by the web server itself.

Testing Username and Password Strength for web forms

1. From the Tools Explorer, select the ‘Authentication Tester’ node and in the ‘Target URL to test’ edit box and specify the target URL e.g. www.test.com/login/

2. Select ‘HTML form based’ as the authentication method to be used for the attack and click on ‘Select user/password form fields to use’.

3. In the ‘Parse Web Forms from URL’ screen, the application will display all the available fields contained in the target page, as shown in the screen shot above.  Indicate the form field that represents the username, by clicking on the field and clicking on ‘Username’ button.  You have to also indicate the form field that represents the Password by clicking on the field, and clicking on the ‘Password’ button at the bottom of the window.

4. Acunetix WVS must be instructed what constitutes a failed login page so the application realizes the appropriate behavior upon successful login.  Using a web browser, attempt to log in to the page to generate a login error and note down the text that indicates a login failure.  Set ‘Logon has failed if’ to ‘Result contains’ and copy the text that indicates a login failure in the input text box.  Regular expressions can also be specified by choosing ‘Result matches regular expression’. Click ‘Start’ to launch the dictionary attack against the web form.

Note: If there are multiple forms on the page, they will be parsed and shown in this dialog.  Select the form which contains the relevant authentication fields.

Importing and Writing HTTP Requests

The Blind SQL injector needs to know the exact HTTP request from where the remote user can inject data into the database. You can import a HTTP request from a reported SQL injection in a website scan or else write a HTTP request yourself and add an SQL injection point anywhere you would like in the request.

Importing the HTTP Request

From the scan results of a website, right click a reported SQL Injection and select ‘Import to Blind SQL Injector’. This will import the HTTP request used to discover the SQL Injection in the tool, including the injection point for further analyzes.

Writing the HTTP Request

The HTTP request can be written manually as plain text in the HTTP Request tab.

Injection Point

Specify the exact point where the injection point should be placed by placing the cursor at the insertion point and click on the ‘+’ icon from the toolbar. This will insert the ‘${InjectHere}’ token, which will be replaced dynamically by the injection engine using various injection techniques.

Blind SQL Injector Tools

1. File Extraction Tool

With this tool you can extract files from the web server by exploiting the discovered SQL Injection.  This is possible if the injection is already validated. Configure the following options to extract files:

• File Name – Specify the exact remote path and filename of the file to extract
• Offset – Specify the character index from where you want to extract data
• Length – Specify how many bytes to extract from such file. Set it to 0 for no limit, i.e. extract all file
• Text File – Tick this option if file is a text file. In this case the extraction algorithm knows it is a text file, making the extraction process much faster.

Note: Once ‘Extract’ is clicked, if the file extraction is successful you will be prompted to specify a location and filename where to save the extracted file.

2. Execute SQL Query Tool

This tool lets you execute arbitrary SQL queries on remote SQL server. The query can only return 1 row and 1 column, therefore the SQL query has to be limited.

• SQL query – Write down the SQL query in this text box
• Offset - Specify the character index from where you want to extract data
• Length – Specify how many bytes to extract from the result returned from the SQL query. Set it to 0 for no limit, i.e. extract all result.

Note: Once ‘Extract’ is clicked and the SQL query results are successful, you will be prompted to specify a location and filename where to save the results.

Configuring the Blind SQL Injector

Configuration of the Blind SQL Injector can be accessed from the ‘Settings’ tab in the ‘Blind SQL Injector’ node.

Settings > General Tab

• Database Type – Select ‘Automatic’ if the database server is unknown and the blind SQL Injector will try to guess it.  Else, if the SQL server is known, select it from the drop down menu.
• Extraction Method – Select ‘Automatic’ and the tool will try to use the best method possible. ‘Condition based’ extraction method is the most reliable but slowest. Using ‘Union Select’, in some limited cases when the SQL query and injection point permits, the tool will inject in the existing queries other queries but in a direct way, so this method is up to 8 times faster than the previous one.
• Minimum HTTP Retry – The number or retries the application will take before reporting a connection error.
• Encode SQL Spaces with /**/ - Tick this to encode SQL spaces with /**/. This is a basic way to fool anti SQL injection algorithms.
• Force HTTP encoding of the SQL string – Tick this option to automatically encode SQL strings used in a GET parameter.
• Encode all characters – Tick this option to encode all characters not just the special characters.
• Encode spaces with plus – Tick this option to encode spaces with a ‘+’ sign instead of %20.
• Show debug information – Enable this option to enable debug logging in the application log.

Settings > Condition Based Extractor node

• Injection SQL string > Automatic Detection – Tick this option if you want that the injection string to be injected in the SQL is determined automatically by the tool.
• Injection SQL String > provided by user -. Select this option to manually specify the Injection SQL string. The condition place is given by the ${condition} token, e.g. 1 AND ${condition}/*.
• True / False condition detector > Automatic – Select automatic for automatic detection. It may not work if more subtle changes occur in the server response, between consecutive requests.
• True / False condition detector > Provided by Regex – Specify the regular expression which must match the response data on true condition.
• Inverse Regex – Enable this option when you want that the true condition is triggered when the condition of the above stated regex is false.
• Character Extractor
  • Bit Method – Select this option to quantize the characters directly to bits and do test on the bits.
  • Half Method – If this method is selected, the application will try to find out the numerical value of the character by using the half method, i.e. it will try to find a value in a given interval always splitting the interval in half and testing in which of them the value is, and do this recursively.
  • Try Parallel request – Tick this option to request all bits in parallel.

Settings > Union Select based extractor tab

• Start Column number – Specify the minimum number of columns expected in a database.
• Max column number – Specify the maximum number of columns expected in a database.
• Visible column index – Specify a column which the Blind SQL injector can already extract. This setting is used as a reference from the tool. Leave as 0 to set as auto.

Note: If a database you are scanning may include more than 20 columns per table, increase the value in ‘Max Column Number’.

Creating a rule to automatically test a series of inputs

As an example, a rule will be created to test the products section of the Acunetix test website using a range of values to find out what products are listed in the database.  The scanner will be set to automatically replace the variable part of a URL with a series of values. In the URL, the last part?cat=1 is the variable part.

http://testphp.vulnweb.com/listproducts.php?cat=1

Note: The example in this manual is only meant to show the capabilities of the HTTP Fuzzer.  With this tool much more advanced tests can be done.

Gathering a HTTP Request

If a valid HTTP request is known, paste it in the ‘Request’ tab in the HTTP Fuzzer.  Else, load a saved scan or crawl, right click one of the files in the results tree and select ‘Export to HTTP Fuzzer’.

Creating data generators

First you must determine which part of the request will be used for fuzzing.  This value will be replaced by a data generator.  Below is a step by step procedure how to create a data generator;

1. Click on the ‘Add Generator’ button on the right part of the HTTP Fuzzer window.

2. Select the appropriate generator type from the drop-down list, which can be any of the below;

• Number generator – This will generate all range of numbers from a start number variable to a stop number variable, using the specified increment.
• Character generator - This will generate all the ASCII characters contained between a Start character variable and a Stop character variable using the specified increment.
• File generator – This will feed all the strings from a specified text file. In the file, each variable string should be entered on a new line.
• String generator – This will generate string combinations with the characters specified in the ‘Character set’ option and with the length specified in the ‘String Length’ option.
• Random string generator - This will generate a specified number of random strings with the characters specified in the ‘Character set’ option with the length configured in the option ‘String length’.
• Character repeater - This will repeat a specified character/string for a given number of times (commonly used for buffer overflow testing).

3. Once a generator is selected, set the parameters according to the test from the window underneath the generators list.

4. After configuring the generator(s), place the text cursor in the specific part of the HTTP Request where the generator will replace the static value. Highlight the static value (e.g. /artists.php?artist=1), and click on ‘Insert into Request’.  The static value will be replaced with the generator variable, e.g. /artists.php?artist=${artists_id}.

Creating Fuzzer Filters

Click on image to enlarge

To create a Fuzzer filter, click on the ‘Fuzzer Filters’ button in the toolbar to open the filters dialog. To use a predefined filter template, select the rule template from the dropdown list; otherwise custom filters can be created by defining the following parameters:

• Rule description – A name to describe the rule
• Rule Type – Select if the rule will be used to Include or Exclude the result returned because of the filter, or if it has to be logged in the ‘Activity Window’
• Apply To – Indicate where to search for the matching expression, if in the HTTP response headers, body or status code
• Regular expression – The regular expression or text which will be searched to match the rule.

Note: Ensure that the relevant checkboxes are ticked to enable the created filters.

Scanning a domain for Subdomains

Enter the Top Level Domain Name in the ‘Domain’ input field, e.g. acunetix.com.  Then select the DNS  Server to use from the drop down menu; or use the target’s DNS server i.e. the authoritative name servers for the domain, or specify a DNS server of your choice.

The default timeout specified is an optimal setting; 10 seconds.  Increase the timeout value if requests are timing out.  Once the scan is finished you can right-click the discovered subdomains to launch a scan against them, or send custom requests using the HTTP Editor.  You can also export the list of subdomains to a text-file to be imported into the scan wizard, or export the results to a CSV file.

To Start a scan enter a single IP or a range of IP’s to be scanned, e.g. 192.168.0.1-100.  If the web servers to be scanned are listening on non default ports add the port numbers to the ‘List of Ports’ entry field.

Discovered web server/s is/are displayed in real time mode, as soon as they are discovered.  The server type, hostname and server banner are also retrieved.  HTTPS web servers are identified by a padlock icon .

You can right-click the discovered web server to launch a scan against it, or send custom requests using the HTTP Editor.  You can also export the list of discovered web servers to a text-file to be imported into the scan wizard, or else export the list of servers to a CSV file.

I believe the reason why getting developers on board with security is not so cut and dried is something called the expediency principle. This principle says that people are going to take the fastest and easiest routes to get what they want without regard for the long-term consequences of their actions. Putting the expediency principle into software development terms: developers are going to develop software (the thing they want or have to do) in the quickest and simplest ways possible often ignoring the outcome of their choices (software security flaws that can be exploited for ill-gotten gains).

So what’s to give? If developers are going to take the path of least resistance, why even bother? The reality is, developers behaving in this fashion don’t have buy-in. It’s not that they don’t care. Rather it’s that developers are often not being held accountable. But how can we get them on board with security? I’m not saying it’s going to be easy but it is possible. Here are several things you can do right now to get started:

1. Find an advocate on the development team who’s interested in learning more about security and ultimately making things better for the business.
2. Get someone in management involved (i.e. the CTO, CIO, or CFO) who can not only set expectations and hold people responsible but also lead by example.
3. Invite developers to IT, compliance, security, and internal audit meetings so they can see how their actions affect these areas of the business.
4. Show developers what can happen when security flaws are exploited. Quite often developers haven’t even had a chance to slow down and think about the outcomes of XSS, SQL injection, session manipulation and so on. Some real-world examples can go a long way.
5. Share with them – even show them the ins and outs of – a good Web vulnerability scanner such as Acunetix Web Vulnerability Scanner that’s available to them throughout the development process.
6. Have them help you formulate a set security standards and policies that apply to software development across the board in your business.

Finally, it’s important to understand the reasoning behind why people do what they do. Psychologists have determined that people do things for two reasons: the desire for gain and the fear of loss. In other words, people want to get something positive (money, recognition, promotion, etc.) or they’re afraid they’re going to get into trouble (miss key system requirements, cause the business to fail to meet contractual or compliance requirements, get fired, etc.) as a result of their actions. This translates nicely into developers writing security code.

If we as information security professionals are going to get the right people on board in the right ways to improve software security it’s going to take some work. It’s all a matter of choice.

The below video shows how an attacker may exploit a cross-site scripting vulnerability on Facebook.com regardless of the HTTPOnly cookie protection used. Of course, this goes way beyond showing an “alert()” popup in Javascript, since the attacker is also able to hijack the victim’s Facebook account. We also published an article to explain in more technical detail the works behind abusing this Cross-Site scripting vulnerability on Facebook.

Click here for high quality version of this video (opens a new window)

We worked with Facebook to make sure that this vulnerability is fixed. We would like to thank their security team for quickly fixing it.

The @RISK alert lists 69 unique Web-related flaws across numerous platforms. The flaws run the gamut from cross-site scripting to SQL injection to directory traversal to local file inclusion. Sure, some – perhaps many – of these issues are likely not a big deal in the grand scheme of things. But do you know for sure?

One thing I’ve seen over the years is people performing – or scoping for – assessments of their main (often external-facing) Web sites and applications and stopping there. After all, the “less important” sites and applications don’t really house anything of value. Combine that with the fact that many of these systems are only accessible via the internal network where, supposedly, no one’s going to exploit them?

Don’t get me wrong. I’ll be the first guy to recommend that you focus on your most urgent vulnerabilities present in your most important systems. Many organizations have yet to begin to reach that level of security insight and maturity. And unless and until they do, then focusing on the low-hanging fruit is going to have the highest payoff. However, for many others who have things under control, it may be time to take the next step and see what else in your environment is creating risk. This means scanning your entire network – both inside and out – for Web-based systems you might have overlooked. Acunetix Web Vulnerability Scanner’s Target Finder tool is great for this. You’ll likely be surprised at what you find.

On any given network there are often several dozen Web-based systems beyond the highly-visible ones. Think about it – there’s a Web interface on practically everything these days including:
• Firewalls
• Network switches
• Wireless APs
• Physical security/data center control systems
• CCTV surveillance systems
• VoIP phones and call managers
• SAN and NAS-based storage systems
• Copiers and printers

…and so on – all of which are sitting on your network waiting to poked and prodded by an external attacker or rogue insider. Looking at the SANS @RISK and similar vulnerability alerts shows that vulnerabilities do indeed exist on these odd systems.

The question is do you know how secure these systems are on your network? Could a Web exploit on a seemingly unimportant system be exposing sensitive information or lead to further system penetration? Odds are in your favor that there’s not much to be concerned with. The only way you’ll know for sure is to scan these systems and perform a manual analysis to verify for yourself.

On the 4th of July 2010 YouTube users began complaining that their videos had been hijacked, the comments section of their videos seemed to be most severely affected, many complained that old comments vanished and new comments could not be added. Others reported that offensive messages were popping up on their screen or scrolling horizontally in large fonts and striking colors. Some users also seemed to suggest that there were experiencing page redirects, often to sites promoting pornographic content.

YouTube users voiced their experiences on YouTube message boards, Twitter and other social networking sites. Within minutes it was apparent that the YouTube website was under attack.

YouTube’s XSS (Cross Site Scripting) defenses had been defeated. Security-minded people began shouting warnings, asking users to stay off YouTube. Other YouTube users urged others  to log out from their account, for fear of cookie hijacking, and other nasties caused by XSS attacks.

Above: Some users reported this screen when browsing the YouTube site during the attack.

Within an hour or two the problem was fixed, YouTube servers were cleaned out, rebooted and the Internet as we know it was restored to normality.

Very few realized that what they had just witnessed was probably the single most embarrassing and largest security breach that Google has ever suffered. This flaw could, and probably will, tarnish Google’s reputation and raise new awareness to everyone. People ask; how can Google, and YouTube suffer from such a classic XSS attack as this one?

The YouTube XSS Vulnerability Explained

In XSS (Cross Site Scripting) attacks such as this one the attacker manages to ‘inject’ JavaScript code into the target website. Many different techniques exist to do this, if you are interested, Acunetix recently posted an excellent article on their security blog, explaining different XSS techniques (Cross Site Scripting – XSS – The Underestimated Exploit.)

In this attack the Comments feature of YouTube videos was targeted. The attacker would simply paste his malicious script into the comments field that is available under videos on the YouTube website.

In it’s simple form, the user would put in a comment such as this one:

<script><h1><marquee><font color=”red”><u>HaHa – This text will scroll in red, on your screen</script>

In this particular attack, the keyword IF_HTML_FUNCTION? appears after the <script> tag, in the following way:

<script>IF_HTML_FUNCTION?<h1><marquee><font color=”red”><u>HaHa – This text will scroll in red, on your screen<script>

Apart from this keyword, I also noticed that the <script> tag is not properly closed. This is probably what caused other scripts on the same page to stop functioning.

During the time the YouTube was vulnerable users began creating variants of the marquee script, one of which would redirect users to Goatse, an infamous hacker web site, as can be seen below.

<script><BODY onLoad=”var a = ‘\x68\x74\x74\x70\x3a\x2f\x2f’ + ‘\x77\x77\x77\x2e’ + ‘goatse’ + ‘\x2efr’; location.href = a;”

One thing to note about this attack script is that the IF_HTML_FUNCTION? is missing, but the <script> tag is still not properly closed.

Videos emerged of other users experimenting with this newly discovered flaw. One user made a video of himself exploiting the following script, which will have the effect of making the entire page black, except for the words *TEXT HERE*:

<script><h1><marquee style=”position: absolute; top: 0px; bottom: 0px; left: 0px; z-index: 9999999; right: 0px; background-color: rgb(0, 0, 0);”><font style:=”font-size:60px” color=”red”><u style=”">*TEXT HERE*<script>

Similar to the previous two examples, the <script> tag is not properly closed, and just like the example before this one, the IF_HTML_FUNCTION keyword is missing.

By the time I go around to creating my own experiments, YouTube had already fixed the problem, they also very briefly, and without detailed, admitted to the attack (Google acknowledges YouTube hack.)

The fix was swift and effective, however it impeded me from carrying out further tests, so I was not able to determine what would happen if, for example the <script> tag was properly terminated.

Lessons Learned and Countermeasures

It is still not clear whether this attack existed for a long time but never noticed, or whether it was a recently introduced bug; hopefully YouTube will explain to us how this XSS vulnerability was made possible.

My gut feeling is that a recent software update introduced this security hole; if this is the case, it reinforces what some security experts are saying; incorporate security test in your QA process, preferably with automated tools such as vulnerability scanners. Security testing and vulnerability scanning are not exercises that are done once and then never again. They need to be re-done each time a software update is made to your web apps. In the case of YouTube, this is probably a daily exercise.

This attack is  a stark reminder of how vulnerable Internet users are to XSS attacks. A classic and relatively simple attack worked against the biggest Internet giant. If Google and YouTube cannot keep their users safe, then who can?

Acunetix Web Vulnerability Scanner

“In comparison, our work, to the best of our knowledge, performs the largest evaluation of web application scanners in terms of the number of tested tools (eleven, both commercial and open-source), and the class of vulnerabilities analyzed. In addition, we discuss the effectiveness of different configurations and levels of manual intervention, and examine in detail the reasons for a scanner’s success or failure.”

“we decided to create our own test application, called WackoPicko. It is important to note that WackoPicko is a realistic, fully functional web application.  As opposed to a simple test application that contains just vulnerabilities, WackoPicko tests the scanners under realistic conditions. To test the scanners’ support for clientside JavaScript code, we also used the open source Web Input Vector Extractor Teaser (WIVET). WIVET is a synthetic benchmark that measures how well a crawler is able to discover and follow links in a variety of formats, such as JavaScript, Flash, and form submissions.”

Download the paper “Why Johnny Can’t Pentest: An Analysis of Black-box Web Vulnerability Scanners” from here.

For more details about the OWASP AppSec conference click here.

The image below shows just a snippet of the information harvested by the attackers. You will notice that in this list exist many US Military and Government email addresses. This begs the question; why are users of the US Whitehouse, DARPA and army using their government email address for their iPhone subscriptions?

Sample of data stolen from AT&T website

The flaw in detail

The mistake in the AT&T website software was subtle, but the results were very damaging. At the core of problem lies in a script on the AT&T website: https://dcp2.att.com/OEPClient/openPage

This script takes one parameter called “ICCID” and another, which apparently is ignored called “IMEI”. If a valid ICCID is passed, the script will respond with the email address of the ICCD subscriber. For those wondering, the ICC-ID stands for Integrated Circuit Card Identifier. It is a number that associates a SIM card with a subscriber, so every iPhone and iPad user has one. If you have an iPhone or IPad, you can find your ICC-ID number from the About screen as shown in the image below.

ICC-ID display in Apple iPhone about box

The script will be invoked remotely using a standard HTTP GET request, that will look something like this: https://dcp2.att.com/OEPClient/openPage?ICCID=89014103211479197174&IMEI=0

This request is legitimate, and therefore was not detected by AT&T when the breach occurred, allowing the hackers to harvest a huge number of email addresses before they announced the hack to the world.

The attack script

Goatse Security, the group behind this exploit revealed the PHP script that they used. This allowed security researchers to peek ‘behind the scenes’ and see what techniques were used.  Below is the script, titled “iPad 3G Account Slurper”.  I bolded the sections I found interesting, and which I will explain further down.

Click on script to enlarge image

This script is not a work of art (like most PHP code out there), but it does the trick. Here are the portions I find most significant.

$useragent=”Mozilla/5.0 (iPad)”; //Spoof as iPad

The line above sets the HTTP User-Agent header to the one that the iPad uses. This makes the AT&T website believe that the request came from an iPad. Generally, its a bad idea for web applications to rely on the user agent because this field can be spoofed very easily.

while (1) { //Continue FOREVER

This line instructs the script to keep running forever, or until a human turns it off. During this hack it was allowed to run at least 100,000 times, however there is no limit to how many email addresses could be harvested. This line also shows the programmer’s confidence in the fact that his attack cannot be detected, especially if he uses proxies to continuously change his IP address (another common technique used to avoid detection due to too much traffic from one source IP.)

$ICCID = $ICCIDroot.genluhn(strval($ICCIDroot)); //Generate checkdigit and attach it to the ICCID

This line creates a new ICC-ID, which will be used later. The ICC-ID has something called a “Check Digit”. This is a number derived and appended to the ICC-ID itself, and was supposedly created to detect ICC-ID corruption and to minimize spoofing. With a touch of ingenuity the programmer includes an algorithm in his script that re-generates the check digit for every ICC-ID attempted. This ensures the integrity and validity of the ICC-IDs he spoofs.

curl_setopt($ch, CURLOPT_URL, “https://dcp2.att.com/OEPClient/
openPage?ICCID=”.strval($ICCID).”&IMEI=0″);

This line is the ‘core’ of the script, and is the one that crafts the URL that will be used to harvest email addresses. It is strange to me, that the IMEI is always set to 0. I am only speculating, but it might have been possible to avoid or seriously thwart this attack if the IMEI associated with the ICC-ID was validated.

if (preg_match(“<input id=\”email\” name=\”email\” type=\”email\”
placeholder=\”Required\” value=\”.*\@.*\” autocapitalization=\”off\”
autocorrect=\”off\”>”,
$output, $match)) {

The line above is a very crude (I repeat, very crude) way of parsing out the email address from the served HTML. It uses the powerful regular expression library (RegEx) in a very loose way, however it seems that it did the trick for the hacker. It does indicate, however that the script was written in a hurry.

Preventing this type of attack

This attack does not exploit and XSS (Cross Site Scripting), SQL Injection or CRLF injection techniques. In fact, looking at the PHP script reveals that the attack would have been impossible to detect, even if a Web Application Firewall was used. This type of attack can only be prevented by implementing proper quality controls.

1. You don’t have any desired outcomes from your scanning other than a PDF report you can share with management. Put nothing into your scans and you’ll get exactly that.
2. You’re using an outdated, unproven, “free” scanner because people on the Internet said it was good. In terms of learning curve, finding the issues that matter, and reporting, a free scanner is often the costliest tool of all.
3. You haven’t bothered to at least read the included documentation to learn the basics on how to use the scanner. Entering a URL and blindly clicking Go is a surefire way to not only get very little out of what you’re doing but to also create a false sense of security that all’s well if nothing is found.
4. You’re doing it to please someone else – or shut someone else up – and aren’t going to take any real action on the findings. Creating the facade that you’re doing the right thing in the name of “audit” or “compliance” creates more risks than it mitigates.
5. You’ve gotten the impression that all you have to do is look for Web security issues that match the popular top Web vulnerability lists available on the Internet. Just because a certain set of vulnerabilities happen to be the most common doesn’t mean you’ll have them nor does it mean you won’t have extensive issues beyond them.
6. You’re prepared to announce to management that the sky’s falling and the plug needs to be pulled on your business’s Web presence simply because it appears a huge flaw is present. Making a big deal out of everything without determining the actual impact to your business is a great way to lose your credibility and put an end to any vulnerability assessment program you’re trying to build.
7. You’ve been instructed to just run a quick scan from the Internet for now. Not looking at an application from every reasonable perspective – both with and without authentication – will rarely serve to give you what you need.

In our world of information security, when it comes to scanning Web systems for vulnerabilities, “good enough” hardly ever is. If your true goal is to minimize business risks then you might as well go about running your Web vulnerability scans the right way. By doing so, you’ll get more out of your money and your efforts, you’ll find security flaws that matter in your environment, and you won’t be surprised when you find out someone else discovered a flaw that you missed.

Go into this with the proper mindset and you’ll do just fine. Jump in headfirst without thinking and you’re setting yourself – and your business – up for failure.

So let me get this straight, Web applications are 1) front and center in most businesses’ Internet presence and IT operations, 2) often have multiple holes that can be exploited for ill-gotten gains, and 3) would likely impact the bottom line if they became unavailable for any given period of time. Yet network managers and security administrators continue to focus their efforts on the network infrastructure. If a breach occurs or an unplanned outage takes place, then by golly the network perimeter isn’t going anywhere. The VPN will stay live, critical internal servers will fail over as planned, and most certainly email’s not going away! Everything is good – well, almost everything.

But what about Web applications? With both external and internal components which would undoubtedly be affected during an incident or disaster are we just going to cross that bridge when we get there? Some may rebut this statement by claiming “Our applications are hosted by a third-party and they have a SAS 70 audit every year so we’re good.” Seriously!? I’ve actually heard this before – from several people in businesses large and small across various industries. I understand that vendors love to tout SAS 70 audits and lawyers like to defer risk to third-parties when they can. But when something bad arises, there’s no audit report, contract, or SLA in the world that’s going to get your business out of a bind. No such document will clean up your business’s tarnished image and nor will it bear the burden of the additional hours that IT, customer service, and others inside your organization will likely have to take on.

My point is, get more involved with your Web applications regardless of where they’re located. A hack, a tornado, you name it will be your problem when it occurs. Be sure to include not only the technical side of your Web applications in your ongoing security tests but also the operational side as well. If you look hard enough you’ll likely find your business is a seemingly small incident away from getting into it real deep.

Keep in mind that most contingency plans (again, assuming they exist in the first place) fail due to lack of sufficient breadth, lack of organization, lack of maintenance, and lack of testing and subsequent refinement. Maybe over the next six months you continue on with your Web vulnerability scans (you’ve got to have them) but perhaps you focus more of your efforts of the soft side of the equation. Risks in that area can surely bite just as hard.

The full advisory is available from the following URL;http://resources.enablesecurity.com/advisories/ES-20100601-dotdefender4.txt

First and most importantly of all, one would be scanning the web farm’s perimeter network and not the website itself.  Therefore if the scope is to secure a website, this is not the right approach.  If the target website is vulnerable to a SQL injection attack, a web application firewall sitting in front of the website might block the scanner’s requests, resulting in the vulnerability not being discovered and reported.

Some might also argue that there is no need to scan a website when there is a WAF sitting in front of it.  After all, it’s from where the attacker has to go in, right?  As a rule of thumb, security is as weak as your weakest point on the network.  Apart from that, there are a number of other reasons why one still has to scan and audit his website directly, and not through its perimeter network, or nothing at all.

• As we’ve seen in the past, web application firewalls can be exploited and bypassed with a number of freely available tools and scripts.   For a malicious user, bypassing a perimeter network and finding an insecure web application is like discovering a hidden golden treasure.  It will only take him a couple of more minutes until he gains control over the website, the web server and penetrates deeper into the corporate network.
• A web application firewall will only delay attacks, and should not be used as a standalone security solution, as recommended by a number of web application firewall vendors themselves.  Usually a web application firewall is used to help beef up the security of the perimeter network, but never as a website or web application audit replacement.  If the budget permits, it is always a good practise to install one.  New attack vectors are frequently discovered, and unless your web application is properly secured, your application can still be hacked, even if it is sitting behind a web application firewall.
• A web application should always function as it was intended to function.  Simple isn’t it?  E.g. if the “Send Email” button in a web form is clicked, and by mistake an email is sent to support@acunetix.com, instead to sales@acunetix.com, then there is a problem which needs to be fixed.  A web vulnerability is a website malfunction, a problem which has to be fixed, always!

Therefore if the scope of the penetration test or security audit is to secure a website or web application, the security scan must always be launched directly against the target, without any ‘man in the middle’ device or software.  The best practise, as always, is to tackle the problem at source, and not trying to hide it or delay its consequences.  In this case then, one should always secure the web application itself.

Also, what’s worse for a consultant than getting stuck at a client with non functioning tools?  “The support of Acunetix WVS must also be praised. They have helped us solve many different issues over time and their responses have always been fast and clear. These are some of the main reasons, why we don’t even consider changing to another web security solution.” Concluded Mr Helbrandt.

Click here to read the full Digicure case study, including requirement details and solutions.

Citizens living in the provinces of Gelderland, Overijssel and Flevoland are being encouraged to use public transport via a campaign that promotes the vulnerable website, from where they can purchase travelling smart cards. “ins3ct3d” also explained that he felt obliged to expose this security vulnerability to warn his fellow citizens as long as the government continues to use such unsafe systems.  ins3cted also stated “This time it’s sensitive personal data, next time your fingerprints or EPD,” which for sure it’s not the kind of data you want falling in the wrong hands!

Till now, there is no confirmation if customers’ banking and payment details were exposed, but there were a number of accessible fields in the databases which stored ID card numbers and payment terms.  At the request of Webwereld, a Dutch website which publishes internet related news, the hacker did not retrieve any more data.  The vulnerable site, at this time is currently unavailable.

At least we can breathe a sigh of relief this time, since the hacker appears to have interest in exposing poor coding security, rather than stealing identities.  Hopefully this incident will raise much needed awareness around the world of the need to ensure secure development and web application penetration tests.  The video is available from the following URL; http://webwereld.nl/nieuws/66012/ov-site-lekt-persoonlijke-data-168-000-reizigers.html

Security policies state nothing more than “This how we do things around here”. They help set everyone’s expectations, ensure things get done, and – most importantly – hold people accountable. Whether you have an existing Web security testing policy or you need to create a new one, it’s good to have a formal structure to the document that clearly conveys the right information. The following security policy template can do just that:

Introduction: An overview of what the policy covers such as vulnerability testing for all Web-based production systems.

Purpose: The high-level goals of the policy such as ensuring application vulnerabilities are analyzed on a periodic and consistent basis in order to minimize business risks.

Scope: The sites/applications, business units, etc. that are covered or affected.

Exceptions: The sites/applications, business units, etc. that are exempt from the policy such as non-Internet facing systems, non-business-critical applications, test environments, and so on.

Roles and responsibilities: The team members involved such as developers, QA, IT staff along with what’s expected of them when implementing and enforcing the policy such as specific methods to follow, reporting requirements, remediation follow-up, and so on.

Policy: Your actual policy statement such as: Web security vulnerability assessments are performed on a quarterly basis (external systems) and bi-annual basis (internal systems) or before any new code releases or upgrades in the Web server software or operating system(s).

Procedures: Detailed steps on carrying out the policy such as running automated vulnerability scans using Acunetix Web Vulnerability Scanner from both an untrusted outsider’s perspective as well as an authenticated user’s perspective (all role levels), manual validation of vulnerabilities discovered by the scanner, and manual analysis of the application for additional weaknesses the scanner cannot uncover.

Compliance metrics: The steps that will be taken to ensure the policy is working and everything is in check such as internal audit spot checks, quarterly and bi-annual reports to management, and/or annual validation by a third party.

Review and evaluation: The specific timelines for reviewing and updating the policy for accuracy, applicability, and so on such as once per year or after any gaps or deficiencies in the Web security testing process are discovered.

Sanctions: Specific consequences for policy violations, such as, This will happen on the first offense, that for second offense, and so on.

References: Laws, regulations, and frameworks, such as HIPAA, HITECH Act, PCI DSS, FFIEC, OWASP Top 10 for 2010, and so on.

Related documents: Other standards, policies, and documentation pertaining to the policy such as your SDLC documentation, security standards document, annual audit report on internal controls, and so on.

Revisions: Ongoing changes made to the policy document such as who, what, when, where, how, and why.

Notes: Notes, lessons learned, and so on in support of future policy management and enforcement.

There are two final points regarding security policies: 1) you may have a niche policy such as this that focuses solely on Web security testing or you may elect to broaden the scope to include all of your information systems. There’s no right or wrong way to do this – just do what’s best in the context of your business and 2) do what you can do convey the message to management that just because a policy exists doesn’t mean that everything is in check and secure. Web security is so much more than that.

Click here to learn more about CRLF injection attacks, and how to find and fix such vulnerabilities in your web applications.

One thing that really jumps out is the document’s visual appeal. The visual enhancements in and of themselves make the OWASP Top 10 much more useful – especially for the less technical decision makers whose approval we’re trying to seek. Beauty’s only skin deep though. The real substance is in the new Top 10’s philosophy and approach. The thing that I believe is most beneficial is the enhanced focus on risk. As I talked about here, business risk is something that’s way too easy to take for granted in the bits and bytes world in which a lot of us live and breathe.

A few key statements about risk that stand out in the document include:

• “What’s My Risk?”
Everyone’s situation is different. You’re not going to find every item in the Top 10 in every Web application. Don’t worry about what others think you should be finding or what your risk level should be but instead determine what matters in your specific environment.

• “You will have to decide how much security risk from applications you are willing to accept.”
Even though a large number of businesses are held to the same compliance standards (i.e. PCI DSS, HITECH/HIPAA, GLBA, etc.) only you and your business leaders (ideally as part of a larger security committee) will know what’s tolerable.

I like how this sentiment is shared throughout the OWASP Top 10 for 2010. The reality is you can never ever forget that – no matter what some vendor, auditor, consultant, or other “expert” tells you – your mileage will vary. What’s critical for someone else could very well be a non-issue for you and your business, hence the importance of understanding bottom line business impact and risk.

The new OWASP Top 10 2010 also has some good information on next steps for developers and “verifiers”(the people performing security assessments) including links to the Application Security Verification Standard for requirements development, OWASP Developer’s Guide for information on building secure apps from the beginning, and the OWASP Testing Guide for techniques on finding security flaws. A couple of new things in the final release that help seal the deal are +O What’s Next for Organizations and +F Details About Risk Factors. There’s no replacement for a comprehensive risk-based application security program and these pages will help you help yourself to fill in the gaps.

We’ve still got to get the word out on the OWASP Top 10. It still doesn’t have the visibility – at least with the right people – it needs and deserves. The best thing we can do is continue to spread the word outside of our information/application security circles and continue to get on the radar of developers, QA analysts, compliance managers, auditors, and executives alike. It’s not just about sharing the document with the right people but showing how it affects the business, and once improvements are being made, how it’s benefiting the business. As with any information security-related initiative, it’s always going to be a work in progress.