VT’s Tech Blog

ZeroDayScan in an online scanner which can scan your site for the following issues:

• Detects Cross Site Scripting attacks (XSS)
• Detects Hidden Directories and Backup Files
• Looks for Known Security Vulnerabilities
• Searches for SQL Injection Vulnerabilities
• Automatically detects zero day bugs
• Performs Website Fingerprinting

Once the service finishes scanning your site for issues and vulnerabilities, it emails you a PDF with what they found for your site.

In order to prevent sensitive security reports like this going out to others, ZeroDay scan asks you to add a text file with some security text to be added to your site. This ensures you can scan only sites which you have control over.

Check out this service at www.zerodayscan.com

Google has released a Web Application Security Scanner over at Google Code. This can be used to scan you site for possible security issues which might be lurking around. Skipfish prepares an interactive site-map for the targeted site by carrying out a recursive crawl and dictionary-based probes.

This scanner is easy to setup on an Ubuntu machine. You’ll need to have the packages for gcc and make installed on your system in order to compile Skipfish from it’s sources. Once you install these, download the Skipfish package from the project download page. Once you download it, unzip the files to a folder of it’s own and head over to that folder in your terminal window and issue a make command by just entering this in the terminal.

make

After the package compiles you can test to see if it was successful by issuing the following command in the terminal

./skipfish -h

This should show you a the Skipfish help screen. If you don’t get that, check the make output to see if there were any errors during the compile process.

Once you get Skipfish compiled and ready on your system, head over to their documentation pages to learn more on how to use this to tool to scan your site.

This tool creates a html report of the scan in the output directory you specify and the output looks like this:

Skipfish has a highly optimized HTTP handling which allows you to achieve up to 2000 requests per second on servers which can take that load. It also doesn’t depend on the technology you use to host and build your web application.

If you’re interested in what types of scans are currently implemented on this tool, here’s what it supports (from their documentation page):

• High risk flaws (potentially leading to system compromise):
  • Server-side SQL injection (including blind vectors, numerical parameters).
  • Explicit SQL-like syntax in GET or POST parameters.
  • Server-side shell command injection (including blind vectors).
  • Server-side XML / XPath injection (including blind vectors).
  • Format string vulnerabilities.
  • Integer overflow vulnerabilities.

• Medium risk flaws (potentially leading to data compromise)
  • Stored and reflected XSS vectors in document body (minimal JS XSS support present).
  • Stored and reflected XSS vectors via HTTP redirects.
  • Stored and reflected XSS vectors via HTTP header splitting.
  • Directory traversal (including constrained vectors).
  • Assorted file POIs (server-side sources, configs, etc).
  • Attacker-supplied script and CSS inclusion vectors (stored and reflected).
  • External untrusted script and CSS inclusion vectors.
  • Mixed content problems on script and CSS resources (optional).
  • Incorrect or missing MIME types on renderables.
  • Generic MIME types on renderables.
  • Incorrect or missing charsets on renderables.
  • Conflicting MIME / charset info on renderables.
  • Bad caching directives on cookie setting responses.

• Low risk issues (limited impact or low specificity):
  • Directory listing bypass vectors.
  • Redirection to attacker-supplied URLs (stored and reflected).
  • Attacker-supplied embedded content (stored and reflected).
  • External untrusted embedded content.
  • Mixed content on non-scriptable subresources (optional).
  • HTTP credentials in URLs.
  • Expired or not-yet-valid SSL certificates.
  • HTML forms with no XSRF protection.
  • Self-signed SSL certificates.
  • SSL certificate host name mismatches.
  • Bad caching directives on less sensitive content.

• Internal warnings:
  • Failed resource fetch attempts.
  • Exceeded crawl limits.
  • Failed 404 behavior checks.
  • IPS filtering detected.
  • Unexpected response variations.
  • Seemingly misclassified crawl nodes.

• Non-specific informational entries:
  • General SSL certificate information.
  • Significantly changing HTTP cookies.
  • Changing Server, Via, or X-... headers.
  • New 404 signatures.
  • Resources that cannot be accessed.
  • Resources requiring HTTP authentication.
  • Broken links.
  • Server errors.
  • All external links not classified otherwise (optional).
  • All external e-mails (optional).
  • All external URL redirectors (optional).
  • Links to unknown protocols.
  • Form fields that could not be autocompleted.
  • All HTML forms detected.
  • Password entry forms (for external brute-force).
  • Numerical file names (for external brute-force).
  • User-supplied links otherwise rendered on a page.
  • Incorrect or missing MIME type on less significant content.
  • Generic MIME type on less significant content.
  • Incorrect or missing charset on less significant content.
  • Conflicting MIME / charset information on less significant content.
  • OGNL-like parameter passing conventions.

You can get more information about Skipfish and download it from their project site on Google Code.

Links:
Skipfish Project on Google Code
Skipfish Documentation
Skipfish Downloads

When I talk to developers about security in web development, I usually get the answer that the security is taken care by the systems team by securing the server and by using the https protocol. In reality that is just the tip of the iceberg on security. There’s much more you should do as a developer to incorporate security into your applications.

First the myth that using https secures your website – Using the https protocol only secures the communication between the browser and the server. What if the user himself is trying to hack your application? It just secures his session and doesn’t provide security for your website or application at all.

Another assumption I’ve come across is using the form action post is more secure than get. Posted data only seems secure since the data is not visible in the url. If anyone on the network is using a packet sniffer, the post data is still visible if data is transferred through http. Here is where using https helps.

Validate your form data on the server even if you have a super cool looking javascript validation on the browser. Clever users are known to disable javascript on the browser to get around your brilliant client side validation. Which means that if javascript is gone, all your form validation on the browser goes kaput.

On the server-side you have to be strict with your inputs via $_GET and $_POST even if you receive data through the https protocol. Use a good input filter library to clean your input data. Go to the extent of typecasting the inputs to the data-type to what you expect it to be. Using raw inputs to print data on screen or write to database is asking for trouble. This is how cross-site scripting and SQL injection creep into your applications.

I’ve seen really insecure applications take a file name from a query string in the url and go ahead and print the contents on screen. It just makes life easy for the cracker by allowing him to enter the path to a system file and mine the data to get into the server. Don’t ever use public data to craft your file include logic in the code, that’s easily exploitable!

An insecure practice which I’ve noticed is programmers use remote includes into the application, to the extent of having html snippets from other sites in their application. This allows users to inject malicious code from their own servers in your application. Imagine what they can do with this kind of power. Don’t allow users to a remote include code from external server urls whether it’s innocent looking HTML or otherwise.

This is not a comprehensive article on security but a quick one to cover some common issues developers have on web application security. If you need more specifics details, let me know by commenting on this post.

After HP & Microsoft’s security tool,  Google’s gotten onto distribuing a Security Audit tool. Here’s Ratproxy which is a passive web security audit tool based on the observation of existing, user-initiated traffic in complex web 2.0 environments.

Detects and prioritizes broad classes of security problems, such as dynamic cross-site trust model considerations, script inclusion issues, content serving problems, insufficient XSRF and XSS defenses, and much more.

Some of the key features ( from Ratproxy’s documentation) :

• No risk of disruptions. In the default operating mode, tool does not generate a high volume of attack-simulating traffic, and as such may be safely employed against production systems at will, for all types of ad hoc, post-release audits. Active scanners may trigger DoS conditions or persistent XSSes, and hence are poorly suited for live platforms.

• Low effort, high yield. Compared to active scanners or fully manual proxy-based testing, ratproxy assessments take very little time or bandwidth to run, and proceed in an intuitive, distraction-free manner – yet provide a good insight into the inner workings of a product, and the potential security vulnerabilities therein. They also afford a consistent and predictable coverage of user-accessible features.

• Preserved control flow of human interaction. By silently following the browser, the coverage in locations protected by nonces, during other operations valid only under certain circumstances, or during dynamic events such as cross-domain Referer data disclosure, is greatly enhanced. Brute-force crawlers and fuzzers usually have no way to explore these areas in a reliable manner.

• WYSIWYG data on script behavior. Javascript interfaces and event handlers are explored precisely to a degree they are used in the browser, with no need for complex guesswork or simulations. Active scanners often have a significant difficulty exploring JSON responses, XMLHttpRequest() behavior, UI-triggered event data flow, and the like.

• Easy process integration. The proxy can be transparently integrated into an existing manual security testing or interface QA processes without introducing a significant setup or operator training overhead.

Ratproxy is currently believed to support Linux, FreeBSD, MacOS X, and Windows (Cygwin) environments.

Links:

Ratproxy @ Google Code
RatProxy Documentation

Related articles by Zemanta

• ratproxy: Rat out those security issues in your Web app
• Google RatProxy looks for cross-site flaws
• Ratproxy: Open Source Site Security by Google
• Google gives away free Web app security scanner

Scrawlr is short for SQL Injector and Crawler, a tool developed by the HP Web Security Research Group in coordination with the Microsoft Security Response Center in response to the widespread SQL injection attacks on the web.

“Scrawlr will crawl a website while simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities. Scrawlr is lightning fast and uses our intelligent engine technology to dynamically craft SQL Injection attacks on the fly. It can even provide proof positive results by displaying the type of backend database in use and a list of available table names. There is no denying you have SQL Injection when I can show you table names!”

Key Features of Scrawlr include:

• Identify Verbose SQL Injection vulnerabilities in URL parameters
• Can be configured to use a Proxy to access the web site
• Will identify the type of SQL server in use
• Will extract table names (verbose only) to guarantee no false positives

Scrawlr which is a free tool has a few limitations which are it’s crawl only upto 1500 pages, doesn’t support Blind SQL injection and will not test for Post parameters for SQL injection. Overall even with these limitations, it’s still a useful tool to check your sites to see if you’re safe from SQL injections.

Links:
Download Scrawlr
Scrawlr Forum

via: communities.hp.com

Google Doctype is an open encyclopedia and reference library. Written by web developers, for web developers. It includes articles on web security, JavaScript DOM manipulation, CSS tips and tricks, and more. The reference section includes a growing library of test cases for checking cross-browser and cross-platform compatibility.

This site’s currently got some good HOWTOs on Web security, DOM manipulation, CSS and styles and more. A worthwhile place to check if you’re looking at some quick reference and help.

Link: Google Doctype

Inspekt is a PHP library that makes it easier to write secure web applications, which works on PHP 4 and 5 and has no external dependencies.

Inspekt acts as a sort of ‘firewall’ API between user input and the rest of the application. It takes PHP superglobal arrays, encapsulates their data in an “cage” object, and destroys the original superglobal. Data can then be retrieved from the input data object using a variety of accessor methods that apply filtering, or the data can be checked against validation methods. Raw data can only be accessed via a ‘getRaw()’ method, forcing the developer to show clear intent.

Inspekt can also be used on arbitrary arrays, and provides static filtering and validation methods.

Project Page: inspekt – Google Code
Downloads Page : http://code.google.com/p/inspekt/downloads/list

If you’re looking at deploying a secure production server for PHP, then you’ve got to check out this tutorial. The tutorial outlines the following :

• System they’ll be using (operating system, functionality assumed, security assumptions)
• Preparing the software
• Installing PHP
• Chrooting the server
• Configuring PHP
• Protecting against CSS and SQL injection attacks

Link: Securing PHP – Creating a secure PHP production environment from Source Code
via: PHPDeveloper.org

If you want to detect and act on  XSS probes and attacks on your PHP web application without too much of coding, here’s a project which delivers. It’s called PHPIDS. It’s an IDS for your PHP application which scans your inputs (without sanitizing it) and checks for XSS attacks based on a rule set. You can get an impact analysis of the attack and act on them accordingly based on the severity.

PHPIDS adds a layer of security over your application without having to retrofit code all over the place. It’s also a useful tool to create reports on attacks without having to parse through all the server access log files.

The scanning rules  can be updated by replacing an xml file, pretty much like a virus definition update

Check their FAQ’s on how to integrate this with your application – it’s pretty simple. They’ve got a demo page where you can go test out the efficiency of the system.

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to.

Link: PHPIDS » Web Application Security 2.0 » Index

If you’re working on PHP 4.x, here’s a tool which checks if your codebase is succeptible to Cross site scripting or SQL injection.

Pixy is a Java program that performs automatic scans of PHP 4 source code, aimed at the detection of XSS and SQL injection vulnerabilities. Pixy takes a PHP program as input, and creates a report that lists possible vulnerable points in the program, together with additional information for understanding the vulnerability.

Pixy still doesn’t support PHP 5 !

Pixy: XSS and SQLI Scanner for PHP