Web Application Testing

Use the OWASP Application Security Verification Standard, don’t just focus on the OWASP Top 10 Vulnerabilities.

Maybe I should just say w3af and let it go at that. Or refer you to “H.O.T. | Security” [pdf] by Luis Rocha for hands-on training.

Application availability, confidentiality, integrity and authenticity (collectively: security) are best addressed by organization procedures; see Framework. Implementation reviews are not the time to introduce the topics of availability, confidentiality, integrity and authenticity; that is, implementation reviews are not the time to ask “how do we secure the application?”

Web applications are a portal into your business, and should be reviewed for availability, confidentiality, integrity and authenticity issues. Web applications are also hosting platforms for malware (see the Web Hacking Incident Database). A business presence which hosts malware risks loss of business.

Web application vulnerabilities can fall into two categories:

  • Logical vulnerabilities or problems with application design
  • Technical vulnerabilities or problems with application implementation

For example, changing an HTML form element to a value that the application expects (frequently called a “valid” value) such as changing “FALSE” to “TRUE” could result in gaining access to data you should not have access to. This would be a problem with the application design (a logical vulnerability, assuming you can trust the supplied values) resulting in information disclosure or information integrity issues due to privilege escalation. Logical vulnerabilities are difficult to test for with automation. Watchfire produced a clear explanation [pdf].

Technical vulnerabilities arise through unexpected HTML form element values (frequently called “invalid” values). A telephone number should not contain Javascript code, for example. Cross-site scripting and SQL injection vulnerabilities would be examples of technical vulnerabilities. Automated application testing has a good chance of detecting technical vulnerabilities.

Opportunities for error, server side:

  • Injection
  • Authentication (see OWASP ASVS 2014 v2.18 and v2.20)
  • Access Control
  • Vulnerable libraries
  • Forge HTTP headers
  • Abuse business logic
  • Security configuration
  • Accept forged requests

Opportunities for error, in transit:

  • Steal Cookie
  • Guess Cookie
  • Reuse Cookie
  • Steal Data

Opportunities for error, client side:

  • Malicious JavaScript (XSS)
  • Generate forged requests
  • Stolen clicks (clickjacking)

Pre-production, test environment web application testing should not be treated the same as production web application testing. Pre-production, your goal is to discover problems with the application before anyone else does. (“Can the application misbehave, be abused, expose information that we had not intended to expose?”) Post-product, your goal is to discover if anyone has discovered problems which you have missed. While “security is transient” and testing approaches improve, you cannot perform the same pre-production tests when using production data. These pre-production tests might corrupt a database or cause the database to become unresponsive. Information integrity and information availability are two goals of information security.

At this point you should be wondering “isn’t trying exploits against production data how you do penetration testing? Don’t you need to do penetration testing? Doesn’t PCI DSS require penetration testing?” All are good questions, all are worth a special rant. All are reasons why penetration testing starts with a contract.


Learn how to make web apps more secure. Do the Gruyere codelab.

Tip: You want a change control policy. You want to review changes before they are made. This goes for web page content as well. This is your opportunity to catch the information disclosure problems. Containment after publication is at least difficult and arguably not possible.

Tip: Check each input value to make sure it is an expected value, and assign input values to local variables for use. Specifically, PHP developers should never use anything like $_GET or $_POST. Filtering all data from external sources is the most important security measure a developer can take when coding an application that requires input from the URL. This can be as easy as running some simple built-in functions on your variables. Further coding tips at Gruyere Lessons On Secure Application Development.

Some Best Practices:

  • Disable PUT and DEL on your web server.
  • Explicitly set [HttpGet] and [HttpPost]
  • [Authorize] at controller level
  • [RequireHttps]
  • Beware [AllowAnonymous]
  • HTTPOnly, Secure on custom cookies
  • CustomErrors mode on
  • httpruntime enableVersionHeader=”false”
  • maxInvalidPasswordAttempts=”5″
  • passwordAttemptsWindow=”10″
  • Encrypt and hash Viewstate (Webforms)
  • Headers (see OWASP’s List of useful HTTP headers):
    • Secure
    • Strict-Transport-Security (enforces HTTPS)
    • X-Frame-Options (anti-clickjacking)
    • X-XSS-Protection (anti-reflected XSS)
    • Content-Security-Policy (Anti-XSS, etc.)
    • X-Content-Type: “nosniff” prevents the browser from guessing a content type

Tip: You want a testing framework. I want a testing framework. The role of a framework is to specify, at a high level, the concerns and questions you need to address. Break the high level questions into successively lower level questions. Develop procedures and tools to address these lower level questions. Review you framework and its questions. So where do you find such a framework? There’s the OSI model. Not too helpful when we’re already focusing on web application testing. Don’t forget that there are six other layers. Surely there’s a more fleshed-out framework to build upon. Perhaps one of the following resources will prove useful.

  • Web Security Testing Cookbook
  • Core Security Technologies Research Projects Upcoming: the automated SQL injection vulnerability assessment process. Currently:
    • A Penetration Testing Research Framework
    • Attack Payloads with applications to Botnets
    • Attack Planning
    • Attack Simulation
    • Automated Tracking of Malicious Data in Web Applications
    • Bugweek and Security Vulnerabilities
    • Core Grasp
    • Core Truss and Secure Triggers
    • Core Wisdom
    • CoreTex
    • Development of an Information Security Research Community
    • Gfuzz
    • MD5 considered harmful today
    • ND2DB Attack
    • NERDS – A Public-Key Encryption Scheme
    • Non-Euclidean Ring Data Scrambler (NERDS) public-key encryption
    • Open Brainstormings
    • Practical and Theorical Research Topics in Information Security
    • Protocol Design Flaws
    • Public-Key Cryptography Based on Polynomial Equations
    • Security Event Visualization and Analysis
    • Security Vulnerability Research
    • Software Protection and Licence Enforcement
    • Source Code Auditing Techniques
    • SQL Agent
    • Teaching Penetration Testing
    • Timing Attacks for Recovering Private Entries from Database Engines
    • Using Neural Networks for Remote OS Detection
    • XSS Agent
    • Zombie 2.0 – A web-application attack model
  • OSSTMM – Open Source Security Testing Methodology Manual
  • BackTrack is a Linux-based penetration testing arsenal that aids security professionals in the ability to perform assessments in a purely native environment dedicated to hacking.
  • The Samurai Web Testing Framework (SamuraiWTF) is a live linux environment that has been pre-configured to function as a web pen-testing environment. The CD contains the best of the open source and free tools that focus on testing and attacking websites.
  • SOAP UI Getting Started with Security Testing
  • BURP Suite is an integrated platform for performing security testing of web applications. Its various tools work seamlessly together to support the entire testing process, from initial mapping and analysis of an application’s attack surface, through to finding and exploiting security vulnerabilities.
  • WATOBO – Web Application Toolbox is intended to enable security professionals to perform highly efficient (semi-automated) web application security audits.
  • Suhosin is an advanced protection system for PHP installations. It was designed to protect servers and users from known and unknown flaws in PHP applications and the PHP core. Suhosin comes in two independent parts, that can be used separately or in combination. The first part is a small patch against the PHP core, that implements a few low-level protections against bufferoverflows or format string vulnerabilities and the second part is a powerful PHP extension that implements all the other protections.
  • Web Application Security Consortium features a security scanner evaluation criteria
  • Qualys FreeScan allows small to medium businesses (SMBs) to scan their web sites for of malware, network and web application vulnerabilities, as well as SSL certificate validation, helping web site owners identify risk before hackers do in order to prevent data beaches and protect online visitors from infections.
  • PCRisk free online website malware scanner
  • Venafi Assessor is a downloadable, easy-to-install, free software solution that scans an organization ’s network to locate and analyze deployed digital certificates and the associated encryption keys.
  • Building a Web Application Security Program [pdf] by Securosis, L.L.C.
  • The Web Application Hacker’s Handbook
  • Google’s Browser Security Handbook
  • Let Google notify you if you are hosting malware
  • WPScan is a vulnerability scanner which checks the security of WordPress installations using a black box approach.
  • NTO SQL Invader gives the ability to quickly and easily exploit or demonstrate SQL Injection vulnerabilities in Web applications. With a few simple clicks, you will be able to exploit a vulnerability to view the list of records, tables and user accounts of the back-end database.
  • Netsparker (from Mavituna Security) promises to provide false positive free web application security scanning.
  • TwoLogs offers Test your web form.
  • DOM XSS Scanner is an online tool that helps you find potential Document Object Model (DOM) based cross-site scripting (XSS) security vulnerabilities. To get started simply enter a URL to review the source code of the corresponding resource with DOM XSS sources and sinks being highlighted on the results page. In addition HTML and XML documents will be searched for included external scripts, most likely JavaScript files, that will be fetched in turn and subsequently displayed on the results page.

Note: This post needs to be re-written, split-up and re-organized. Lots of content, little framework.

  • Prevention
    • Secure Application Coding
    • Secure Application Testing
    • Input Filters
    • Patching, or Web Application Maintenance
    • Vulnerability Assessment (including can PHP code be added remotely)
  • Detection
    • Compute Digests of Static Pages and Monitor for Changes
    • Monitor Blacklists
    • Monitor for Malware
    • Monitor for Unintended or Unauthorized Modification (including has PHP code been added remotely)
  • Containment
    • Automated Quarantining
  • Recovery
    • Identify root cause attack vector
    • Patch vulnerable applications
    • Use wrappers or “virtual patching” or “web application firewalls” to make the application appear patched
    • Install clean copies of infected files
    • Install clean versions of infected databases (or clean infected databases)

Prior to implementation, you are testing for application vulnerabilities. See the National Vulnerability Database, The Open Source Vulnerability Database, CVE, Secunia and SecurityFocus. Be reckless, be ruthless. Try lots of exploits. See the Neohapsis Archives, SecurityFocus, Exploits Database, 1337 Exploit Database and the Intelligent Exploit Aggregation Network for leads to such exploits. Post-implementation, avoid disrupting production applications. Focus on testing test for signs that application vulnerabilities have been exploited. Be ruthless with test environments, but cautious with production environments. “Security” is a transient state, meaning people learn about vulnerabilities that that had not thought to test for. If you find signs that a compromise has occurred it does not necessarily mean your earlier testing was lax. If possible, repeat the pre-implementation tests for application vulnerabilities. This may not be possible when testing uses credentials with elevated privileges. You risk corrupting the database of a production environment.

Live Hacking CD is a free Linux distribution packed with tools and utilities for ethical computer hacking, penetration testing and countermeasure verification. Based on Ubuntu this ‘Live CD” runs directly from the CD and doesn’t require installation on your hard-drive. Once booted you can use the included tools to test, check and ethically hack your own network to make sure that it is secure from outside intruders.

The CD includes hacking tools for DNS, reconnaissance, foot-printing (gathering information about computers on the network), password cracking, network sniffing, spoofing (or masquerading) and wireless networking utilities.

WebSurgery is a suite of tools for security testing of web applications. It was designed for security auditors to help them with the web application planning and exploitation. Currently, it uses an efficient, fast and stable Web Crawler, File/Dir Brute forcer, Fuzzer for advanced exploitation of known and unusual vulnerabilities such as SQL Injections, Cross site scripting (XSS), Brute force for login forms, identification of firewall-filtered rules, DOS Attacks and WEB Proxy to analyze, intercept and manipulate the traffic between your browser and the target web application.

Slowhttptest (developed by Sergey Shekyan, Developer Web Application Scanning at Qualys) sends partial HTTP requests, trying to get a denial of service from the target HTTP server. Slow HTTP DoS attacks rely on the fact that the HTTP protocol, by design, requires requests to be completely received by the server before they are processed. If an HTTP request is not complete, or if the transfer rate is very low, the server keeps its resources busy waiting for the rest of the data. If the server keeps too many resources busy, this creates a denial of service. Slowhttptest actively tests if it’s possible to acquire enough resources on an HTTP server by slowing down requests to get denial of service at the application layer.

Slowhttptest is configurable to allow users to test different types of slow http scenarios. Supported features are:

  • Slowing down either the header or the body section of the request
  • Any HTTP verb can be used in the request
  • Configurable Content-Length header
  • Random size of follow-up chunks, limited by optional value
  • Random header names and values
  • Random message body data
  • Configurable interval between follow-up data chunks
  • Support for SSL
  • Support for hosts names resolved to IPv6
  • Verbosity levels in reporting
  • Connection state change tracking
  • Variable connection rate

Detailed statistics are available in CSV format and as a chart generated as HTML file using Google Chart Tools.

Test the application and the environment it is installed upon. nmap (“Network Mapper”) is a free and open source utility for network exploration and security auditing. Nmap 5 cheatsheet [pdf].

ZeroDayScan is a web site to test your web site. Note that I am not endorsing them. You cannot test just any web site; you must be able to place a text file in the root directory of the web site before you can test it. This offers some assurance that you are not using ZeroDayScan for nefarious purposes. The persons behind ZeroDayScan wish to remain anonymous.

Qualys SSL Labs offers an SSL Server Test.

Context Application Tool (CAT) is a free application testing tool that runs on Windows. It runs as a proxy. Features:

  • Complex authorization models
  • Ability to test complex multi-phase forms e.g. single sign-on (SSO) systems
  • Fuzzing forms protected by cross-site request forgery (CRSF) tokens
  • Supporting different encodings used by web services, Ajax and to leverage complex vulnerabilities
  • Ability to perform sensitive timing attacks
  • Heavy Ajax applications

Note: In my configuration, this fails with an installation error:

Error Creating master certificate: The system cannot find the file specified.

DEFENSICS™ Universal Fuzzer is a file fuzzer that can generate security tests for any file structures based on a set of templates. These files can be samples of pictures, videos, documents, or even data packets from traffic captures.

Browser Exploitation Framework (BeEF) will demonstrate the collecting of zombie browsers and browser vulnerabilities in real-time. It provides a command and control interface which facilitates the targeting of individual or groups of zombie browsers.

Enhancements in the latest version include:

  • Integration with Metasploit via XMLRPC
  • Mozilla extension exploitation support
  • New browser functionality detection modules
  • Tiered logging for module actions and results

BeEF is a professional tool to demonstrate the real-time impact of XSS browser vulnerabilities. Development has focused on creating a modular structure making new module development a trivial process with the intelligence residing within BeEF.

Browser Rider is another web browser exploitation framework.

What about a Web Application Firewall (WAF)? A WAF may be a preventative measure, if the action is “block based upon input.” The WAF may be a virtual patching appliance, if it modifies and forwards input, or monitors output, or matches output with input to mask application errors. Akamai offers a WAF [pdf] where “Rules detect and prevent generic threats and exploitation techniques such as SQL Injection and Cross Site Scripting (XSS) attacks, among other Layer 7 attacks.” The Web Application Security Consortium hosts a Web Application Firewall Evaluation Criteria. The criteria is a list of good questions. Use the criteria as a “cheat sheet” to supplement your original question.

Use of “software wrappers” to compensate for application deficiencies began with presenting an approachable interface to one or more legacy applications. You may wish to review the Generic Software Wrappers Toolkit prototype if this a task you ere expecting a WAF to perform.

The small, mom-and-pop web sites cannot assume they will be ignored because larger targets are more attractive. Many web server attacks are random and opportunistic. Search for “Hacked By GHoST61” to see dramatic examples of web sites defaced for no financial advantage. (This is a person who wishes to make known how vulnerable web sites are.) Malicious persons run programs which search for vulnerable web sites. Web sites are found and attacked regardless of size. While the web site itself may not be the direct source of the malicious person’s income, it becomes one of the hundreds of thousands of trustworthy websites which happen to be hosting malware.

Currently in beta: The Infosec IslandTM SMB Security Toolkit.

This suite of tools will allow you to assess and maintain the security of certain portions of your organization’s security that are often overlooked and easy to address. It will also allow you to compare your organization’s security posture with other similarly-sized organizations in your industry.

The Production release of the toolkit will contain the following tools:

For further threat awareness, aee Imperva’s SQL Injection whitepaper [WP-SQL_INJECTION_2.0-1208rev1]. Tools such as Priamos, Power Injector and SQL Ninja automate SQL Injection attacks. SQL Map uses Google to find SQL databases and automatically attack them.

  1. Find an application with an exploitable vulnerability. For this, the Open Source Vulnerability Database can be a useful resource to exploitable vulnerabilities in technologies you are familiar with, as well as sample exploit code.
  2. Find web sites using the identified application or which are misconfigured. SHODAN shows you how little effort this requires. A search for “http://318x.com” will reveal how widespread a single attack has been.

SHODAN is collected server and router information from web presences. This information can be sifted and searched looking for credentials, vulnerable versions of applications.

To find Use Returned
Unsecured HP JetDirect adapters Password is not set port:23 7 in the United States
1 in Germany
1 in the Netherlands
Open FTP servers “331 Anonymous login ok” port:21 488 in the United States
75 in the United Kingdom
74 in Japan
48 in China
Open FTP servers granted port:21 316 in the United States
25 in Norway
23 in Germany
20 in Japan
IIS 6.0 running on Windows 2000 in the United States Microsoft IIS os:”windows 2000″ country:US 82,859 n the United States
Cisco IOS devices with web authentication disabled “cisco-ios” “last-modified”
WatchGuard Firewalls web management console “WatchGuard” “Firewall”
Power management web interface WWW-Authenticate: Basic realm=”APC Management Card”

Note that you can learn about these network presences without actually visiting them. In summary, don’t rely upon the size or nature of your web presence to prevent unwanted information disclosure. This information will be gathered and distributed without regard to the entity hosting the service. Review your systems and the information you disclose.

Larger environments need to be concerned about these random attacks, but they must also recognize that they can expect to be singled-out.  There are other attack approaches which are more targeted. A determined malicious persons will attempt more involved mechanisms to identify information they can put to their advantage.

PAPAS is an automated system that scans web-sites for HTTP Parameter Pollution vulnerabilities.

Google’s Webmaster Console and Microsoft’s Webmaster Tools are free support. Use Google’s Webmaster Console to be alerted when their web crawling detects issues (such as malware) on your website.

Google also has the DOM Snitch extension for Chrome to identify unsafe practises in client-side code.

Michal Zalewski has released SkipFish (read more, download, review by Felix ‘FX’ Lindner):

  1. High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint – easily achieving 2000 requests per second with responsive targets.
  2. Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion.
  3. Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors.

Use SkipFish to collect information about the web application’s “surface” about test those surfaces with other tools.

If you suspect that your web site is hosting malware, you may be able to confirm your suspicions with one of the following. (Hosting malware is only one payload of a successful compromise.)

Arachni is a feature-full and modular Ruby framework that allows penetration testers and administrators to evaluate the security of web applications. Arachni is smart, it trains itself with every HTTP response it receives during the audit process. Unlike other scanners, Arachni takes into account the dynamic nature of web applications and can detect changes caused while travelling through each path of a web application’s cyclomatic complexity. This way attack/input vectors that would otherwise be undetectable by non-humans are seamlessly handled by Arachni.

Static reports

See Metawebsites for additional web sites that may have information about your web site.

Active test utilities

  • vURL Desktop Edition and vURL Online
  • cURL is a command line URL utility (HTTP, HTTPS, FTP). Use cURL to send “malformed” URLs as well.
  • Wget is a command line HTTP, HTTPS and FTP utility.
  • thug is another command line URL utility. If you are attempting to access malware, the target site may refuse to deliver it through cURL or Wget, so use thug. Similarly, the target site may refuse to deliver malware to the same IP address twice.
  • Qualys SSL Labs SSL Server Test
  • Comodo SSL Analyzer for a summary of web server security levels

Cheatsheets

Know your software, know your platform, know your application’s entry points (the intended and the unintended entry points) … know your attack surfaces. Consider the padlock: an obvious attack surface is where you would insert the key (or select a combination), you could pick the lock (or feel the dials). More fruitful is the use of a shim to extract the shackle from the body. Cutting the shackle or body is a third attack surface, but this may have the least probability of success. Know your attack surfaces.

You need a methodology. You need to be able to perform a methodical review of of the web application. You need to be able to look at the web application from many aspects. You need to be able to identify the aspects so you don’t leave the review with an “I forgot to check such-and-such” event. Being caught by surprise by a vulnerability that surprises everyone is one thing (and also the reason you have multiple layers of security) but being caught by surprise by something you forgot to check is another.

Be aware of what threats look like; see Web Security Threat Videos from Imperva. Be aware that threats have been successful; see Industry Data Breach Security Statistics.

Veracode released results (their “State of Software Security Report” subtitled “The Intractable Problem of Insecure Software”) of application code analysis.

Cryptographic Issues Most Common In Applications

Cross-site Scripting Most Prevalent

Microsoft’s Security Development Lifecycle may help you develop your methodology. Note that it is geared toward building in security from product initiation to delivery, which would be the preferred approach. You, on the other hand, may be faced with testing as a final phase. Knowing how development could have been done is still of some help. Additional, there are useful testing tools available.

Test your exposure; there are many web application testing tools that will display your exposure to you, end users and attackers. Call it “penetration testing” (or “pen testing”) is you like. Test changes before implementation; test again after implementation. Test with many utilities. Know your exposure.

Blaming end-users for infecting your servers is not the appropriate attitude. Your end-users want your service, they don’t want to interrupt your service. Expect that your end users run a Trojan horse (a true virus is very rare) and deny that Trojan an attack surface. Expect malicious persons to attack you. Deny them an attack surface, detect them, inform law enforcement.

Be aware of newly announced exposures in your platform by subscribing to vendor and public announcement services. Mitigate those exposures quickly.

“Don’t run Windows” is a short-sighted approach to knowing your attack surface. Denying access to the file system and OS is your continuous monitoring of the attack surface. Virtualization changes your attack surface. The common theme is to identify and mitigate any vulnerabilities in that attack surface.

While you’re busy examining the web-facing threats, don’t neglect to look in other directions. If you’re on a shared hosting service, less vigilant sites on your host could be compromised, and you need to consider any shared processes or shared files systems as additional attack surfaces.

Do not do intrusive web application testing across the Internet. Even with the express written consent of the application owner, hacking a web site across the Internet is illegal (in many countries). The Computer Misuse Act 1990 (UK) and Computer Fraud and Abuse Act 1984 1986 (US) (amended many times, including PATRIOT Act 2001) and US Code Title 18 Chapter 47 Fraud and False Statements places restrictions on unauthorized access or modification of digital material. Reading electronic mail messages exchanged over public e-mail systems by anyone other than the sender and receiver is a felony under the Electronic Communications Privacy Act (ECPA, 18 U.S.C.A ss 2510 et. seq. (1988)). If the application owner wants intrusive web application testing, it should be performed on their side of the firewall. With consent, it is application testing or penetration testing. Without consent, it is illegal (in many countries).

OWASP’s Zed Attack Proxy (ZAP), HttpWatch and Microsoft Fiddler are protocol analyzers (HTTP “sniffers”) which can capture the interactivity with a specific web site and allow you to analyze it (see how it loads and performs). Normally you would not put a protocol analyzer on the Internet. With a network adapter in promiscuous mode, a protocol analyzer or “sniffer” would enable you to see network traffic not intended for you. If email traffic should happen by, you have committed a felony. The Fiddler post-install (congratulations) web page has some information you may wish to know before installing.

x5s is an XSS security testing plugin for Fiddler. Exercise all legs of your application with Fiddler and x5s to find likely XSS vulnerabilities. “All legs of your application” can require human interaction, not a mechanical crawl; see Leveraging User Interactions for In-Depth Testing of Web Applications.

The Open Web Application Security Project (OWASP) consolidates information about how applications are being attacked and how applications can be tested. The OWASP WebGoat Project is a deliberately insecure J2EE web application designed to teach web application security lessons. Join your local chapter of OWASP. The Web Application Security Consortium provides news.

Test skills against (a better list is at IronGeek):

EricLaw’s IEInternals A look at Internet Explorer from the inside out

Unlike other Live CDs, the De-ICE project has no known vulnerabilities; instead, it presents a more real world situation in which system administrators neglected recommended practices.

Among the things you are looking for are error messages. Informative error messages are helpful during testing. In production, informative error messages reveal the technology behind the application (“footprinting”). Organized criminals (previously called “hackers”) collect lists about which targets use which technologies. In this way they are prepared for the next vulnerability. The SHODAN site provides a catalog of technologies and where they are used. For example, a Google search for “Apache/2 Server at” will reveal a large number of web sites using Apache 2.x. This information, along with the availability of a working exploit of a vulnerability in Apache 2.x, effectively means that you advertise that your system is available to whoever would like it. Organized criminals can map the vulnerability to a technology; map the technology to a target; then go after the target before they can mitigate the vulnerability in a planned and tested fashion. You may call this “security through obscurity” is you like, but “security through obscurity” is part of your layered defense. Eschew “security through obscurity” when it is your only layer, but embrace it as part of a multi-layer design.

Getting started: You want to use one of the automated testing tools. Before you do, get an understanding of what the tests are doing. Start with Firefox and a set of plugins: Web Developer, Switch Proxy (use a proxy, such as SPIKE ProxyRatProxy (Google’s testing proxy), burp, webscarab, Paros proxy, or ZAP (Zed Attack Proxy, a fork of Paros proxy) to intercept and monitor your local application traffic), LiveHTTPHeaders and User Agent Switcher (tell the application you are using a different browser or “user agent”), Add N Edit Cookies (modify application state information). Achilles [mavensecurity.com, digizen-security.com] is a free Windows proxy that allows user to examine and modify web content on the fly. A general-purpose web application security assessment tool. Achilles acts as a HTTP/HTTPS proxy that allows a user to intercept, log, and modify web traffic on the fly. Use these tools to manually evaluate your web application and learn the value of automated testing. Use these tools to demonstrate the findings of the automated tools.

See also: How to Setup RatProxy on Windows

An interesting user agent is “Googlebot/2.1+”. How, you might ask, does the Google web crawler find content when you have to log in to view the content? Is Google logging in?

Test your tools and abilities using the NTO Hackme test site / hackme.mightyseek.com. Test using HackThisSite.org. Test using Heorot.net. Practice your testing using a machine on your local network, running XAMPP and Damn Vulnerable Web App. Learn to use the Metasploit Framework with free training from Offensive Security. (Alternate ideas: CoreImpact or Canvas.) Knowing what problems look like builds confidence that you can recognize problems.

Review your applications for well-known vulnerabilities at Secunia.

If additional testing is required, then with written consent or in a laboratory environment, through the book at it: a web application testing tool like WebInspect or Cenzic or Qualys or burp or Core Impact Pro or Netsparker would be your minimal tool. IBM participates in this market through IBM Rational AppScan. You want to test all known methods of exploiting a web application, such as use of certificates, cross-site scripting (XSS) vulnerabilities, information leakage, and buffer overflows. While you could do the same tests with other tools (such as netcat and Nessus), you will be performing these tests repeatedly. You need to address testing the application when the user is logged in. You want consistent testing and reporting. Your testing tool should also make recommendations about next steps or additional reading.

Note that the PCI 6.6 requirement, is not particularly demanding.

  • scan to detect vulnerabilities in web-facing application code,
  • prioritize, manage, and remediate vulnerabilities,
  • scan to validate and document that vulnerabilities have been corrected

Since security is transient (meaning people regularly discover new ways to abuse trust), this procedure should be repeated periodically. Since scanning tools assist you with your evaluation, they should supplement human evaluation, not replace it.

Develop your test suite while you develop your application. It is best to plan to test. Note conditions to remember to test for during development.

Get a baseline, then pound away at it: Fuzzing tools or fuzzers should be used to try variations that you and the testing tool wouldn’t have thought to try. You’re looking for whatever breaks (crashes, slows down) your application. Fuzzing tools for various development environments are available at ThreatMind.

Developers notes: Use a structured exception handler like try {} or catch {} instead of function-based error handling. Do not display default error messages. Remove all debug error handlers before the code goes into production.

The Open Web Application Security Project has instructions and tools for improving the security of application software.

Websecurify is a web and web 2.0 security initiative specializing in researching security issues and building the next generation of tools to defeat and protect web technologies. Caveat:

The tool was designed to provide baseline security assessments only. More advanced and in depth tests require human intervention.

For example, a missing human intervention is the login.

Note specifically security tools at WebScale: Site Timer allows you to analyze some of the most critical aspects of webpage performance. Engine Viewer to view your webpage in the same way a search engine does.

Web Hacking 2.0 – This is BIG Web application testing

Rendezous (optimized for Internet Explorer) is a toolkit for authorized web application testing, from Hidetake Jo. See owasp documentation [ppt].

What are we looking for?

  • Operational Errors
    • Failure to look for known vulnerability issues
    • Information disclosure
  • Configuration Errors
    • Insecure setup of otherwise safe products
  • Implementation Errors
    • Lack of knowledge
    • Lack of correctness
    • Lack of due care, or negligence
  • Design Errors
    • “The Big Fail”

“The Big Fail,” the design error, is often the focus of most security programs, ignoring the other problems.

  • Sufficient authentication controls
  • Cross-site scripting (XSS)
  • Cross-site request forgery (CSRF)
  • Phishing
  • Information leakage
  • Injection flaws
  • Information integrity
  • Sufficient anti-automation
  • PCI 6.6 compliance
check for link
broken links Web QA Test ToolsW3C ValidatorXenulink
Cascading Style Sheets (CSS) CSS Validator
exposed directory structure Nikto (one of the many server vulnerabilities Nikto can discover)Wikto
SQL Injection vulnerabilities WebInspect from HPScrawlr free alternative from HP W3AFGamja Acunetix Web Vulnerability Scanner. Manual, FAQTip/Trick: Guard Against SQL Injection Attacks
sqlmap SQL Injection Prevention Cheatsheet by OWASP SQL Injection attack used in breach of 168,000 Netherlands travelers
Cross-site scripting (XSS) vulnerabilities Cross-site scripting (XSS) is a client attack. If a web application accepts the following text 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");

<a onmouseover=”alert(1)” href=”#”>read this!</a>

<p alert(1)hello

</td alert(1)hello

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 refereed to as “valid data”).

CORE Security TechnologiesGamja

Acunetix Web Vulnerability Scanner. Manual, FAQ

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

XSSploit

Cross Site Scripting cheatsheet from ha.ckers.org

XSS (Cross Site Scripting) Prevention Cheatsheet by OWASP

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.

</xssed>

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

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].
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.
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’.

Automation can be used to identify vulnerability to 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

People are required 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

You can download files from a web site without opening them in a browser. Two utilities to perform this task are curl and Wget for Windows.

file type test with
swf
  • 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!
js
swf
pdf
  • Wepawet is a service for detecting and analyzing web-based malware. It currently handles Flash, JavaScript, and PDF files. Choose to analyze the PDF in its expected context; that is, web-based PDFs would open in a browser.
  • When analyzing a file (rather than a URL), Jsand [wepawet component] does not examine external resources, such as iframes and scripts. In addition, properties such as document.location, document.referer, and document.cookie, which are sometimes used by malicious scripts, are not set.

Remote and Local File Inclusion Vulnerabilities 101 [pdf]

Microsoft provides lots of secure development assistance; try their Security Development Lifecycle blog, for example.

Lots of good web application security information at CGISecurity.com.

Use .htaccess.

IBM offers a Web application security e-Kit.
HTTP REQUEST
============


GET /prototype03/vulnerable.php?vid=zJrt&act=viewed&page=0.01 HTTP/1.0
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR
1.1.4322)
Host: http://www.victim.com
Authorization: Basic dTI0Y29tcGg6PCEzIzw3PjlBQnVu
Cookie:
PHPSESSID=b4499547c0c4f399ba649181d5e67f5c;vid11=6512bd43d9caa6e02c990b0
a82652dca;vid2=c81e728d9d4c2f636f067f89cc14862c;vid4=a87ff679a2f3e71d918
1a67b7542122c;vid8=c9f0f895fb98ab9159f51fd0297e236d;vid9=45c48cce2e2d7fb
dea1afc51c7c6ad26;vid7=8f14e45fceea167a5a36dedd4bea2543
Connection: Close
Pragma: no-cache

HTTP RESPONSE
=============

HTTP/1.1 200 OK
Date: Fri, 29 Aug 2008 10:00:08 GMT
Server: Apache/2.2.9 (Unix) mod_ssl/2.2.9 OpenSSL/0.9.8b
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
PHP/5.2.6
X-Powered-By: PHP/5.2.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html

Suggestions: Disable Apache product tokens. Disable PHP reveal self directives. Headers appear to give away lots of potentially sensitive information.

“Authorization: Basic” is a Base64-encoded representation of a username:password pair, and is reversible (u24comph:

—–

Simple “has PHP code injection attack occurred?” test.

  1. Create baseline list of URLs (where example.com is your site) by doing a Google search for:site:example.com inurl:php
  2. Periodically create new list of URLs and investigate changes.

Cons: This is post exploitation and perhaps long after exploitation. This can be tedious.

Pros: Cheap. Does not require server access.

Not mechanically tested: Credentials. Do not neglect the security of credentials. Malware searches drives for credentials and sends them to a central site. If someone has stored the account credentials (with a browser’s “remember” feature, for example) malware can collect the credentials. Check Prevx to see if your ftp server account credentials appear on one of the malware sites they are aware of. Not finding your account does not mean the credentials are unknown. If no one seems to have used them so far, that does not mean the credentials are unknown. ScanSafe reports manipulated Google Search Engine Result Pages (SERPs) used to install malware that collects ftp credentials; the Gumblar malware spread quickly when it was suddenly added to many web servers using stolen ftp credentials, according to Websense. Change your passwords, use strong passwords.

Not mechanically tested: “Googledorks,” those “what were they thinking?” pages that appear when an organization allows a search engine to crawl pages with information that should not be public. Don’t search for the proprietary information itself, that query is passed in clear text. Search for somewhat unique text that would also be on the page.

Not mechanically tested: Some application might escape your testing because it has not been identified. With so many devices adding web interfaces for ease of maintenance, it is easy to focus upon your web servers and their applications while ignoring embedded devices and their applications.

How would your testing detect a “RansomWeb” attack? Continuous file integrity monitoring would detect this attack. Quarterly penetration testing would miss it.

See also:

IBM Web Application Security e-Kit

Third-Party Web Widget Security FAQ

CORE Security TechnologiesAcunetix Web Vulnerability Scanner. Manual, FAQ

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

XSSploit

Cross Site Scripting cheatsheet from ha.ckers.org

XSS (Cross Site Scripting) Prevention Cheatsheet by OWASP

Azim Poonawala (QUAKERDOOMER) (winAUTOPWN author’s) website: http://solidmecca.co.nr winAUTOPWN and bsdAUTOPWN are available at http://winautopwn.co.nr

winAUTOPWN is an auto (hacking) shell gaining tool. It can also be used to test IDS, IPS and other monitoring
sensors/softwares.Autohack your targets – even if you have consumed and holding a bottle of ‘ABSOLUT’ in one
hand and absolute ease (winAUTOPWN) in the other.

The improved GUI extension – WINAUTOPWN ACTIVE SYSTEMS TRANSGRESSOR GUI [ C4 – WAST ] is a
Systems and Network Exploitation Framework built on the famous winAUTOPWN as a backend.
C4 – WAST gives users the freedom to select individual exploits and use them.

A complete list of all Exploits in winAUTOPWN is available inside MISC\CHANGELOG.TXT
A complete list of User Interface changes is available in MISC\UI_CHANGES.TXT

BSDAUTOPWN has been compiled, like always for various flavours. BSDAUTOPWN is now at version 2.2
The file bsd_install.sh can set chmod on all applicable BSD compiled binaries.

WINAUTOPWN requires PERL,PHP,PYTHON,RUBY and its dependencies alongwith a few others too for smooth
working of exploits included in it.

A complete Document explaining : How to use winAUTOPWN/bsdAUTOPWN, How to add your own exploits using
WELF (winAUTOPWN Exploit Loading Framework), other advanced command-line options and everything else
related to WINDOWS AUTOPWN is available at the Downloads Section.
It is also available online at:
http://resources.infosecinstitute.com/vulnerability-testing-winautopwn/

WINDOWS AUTOPWN – [ C4 – WAST ]
Crafted by : Azim Poonawala (QUAKERDOOMER)

winAUTOPWN and bsdAUTOPWN are available at http://winautopwn.co.nr
Alternative location: http://www.c-4.in/winautopwn

Author’s website : http://solidmecca.co.nr
Blog : http://my.opera.com/quakerdoomer

Web 2.0 Threats Illustrated

PaulDotCom episode 227 discusses WebLabyrinth and counter-webcrawler measures.

See the Phoenix/Tools list at OWASP and Web Application Security Testing Resources at danielmiessler.com.

Vega Web Security Scanner is a free and open source scanner and testing platform to test the security of web applications. Vega can help you find and validate SQL Injection, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information, and other vulnerabilities. It is written in Java, GUI based, and runs on Linux, OS X, and Windows. Vega includes an automated scanner for quick tests and an intercepting proxy for tactical inspection.

Low Orbit Ion Cannon is used to stress test web applications.

CMSmap is a Python open source Content Management System security scanner that automates the process of detecting security flaws of the most popular CMSs. The main purpose of CMSmap is to integrate common vulnerabilities for different types of CMSs in a single tool.


CAPTCHA: a Completely Automated Public Turing test to tell Computers and Humans Apart

Real life examples on hackers bypassing CAPTCHA [pdf]

“’Tis writ somewhat crabbedly, and most damnably long.”

E. R. Eddison, The Worm Ouroboros

Advertisements