Web Application Firewalls do not replace secure development and operation of web applications

In eval($WAF); whitepaper, L. Nothdurfter, W.Neudorfer and M. Kirchner from the University of Applied Sciences Upper Austria, explain in detail how they evaluated the capabilities of some leading WAF’s (web application firewalls), and concluded that although a WAF can raise the security level, secure development and operation of web applications should be of top priority.

As a matter of fact, while evaluating some leading web application firewalls, they also released 3 web application firewall advisories:

• Artofdefence Hyperguard Web Application Firewal (Remote Denial of Service)
• phion airlock Web Application Firewall (Remote Denial of Service via Management Interface (unauthenticated) and Command Execution
• radware AppWall Web Application Firewall (Source code disclosure on management interface)

Some facts about WAF’s, which anyone considering of buying a WAF instead of securing his web application should read(quotes from the white paper’s conclusion):

1. the additional layer of defense (WAF) is partly porous and does not replace the secure development and operation of web applications.
2. It also must not be overseen that a web application firewall is an additional device that is placed between the client and the web server and is therefore an additional device that can have influence on the availability of the overall system.
3. It is also an additional system that can have vulnerabilities or other forms of implementation flaws and requires regular maintenance.
4. Additionally it has been shown that web application firewalls can also be the target of successful attacks (cross-site scripting flaws, cross-site request forgery, denial of service, command execution, etc.)
5. When defining rules for a specific web application or modifying the standard Ruleset it is very important to test the whole web application and all provided functions for their correct functionality.  This can for example be done using automated testing frameworks. In the course of the project often certain functionalities of the web applications used for testing have been rendered unfunctional because of predefined rules of the web application firewalls. As unexpected side effects like this can occur with every change of the rules or the web application itself, comprehensive testing is necessary.

Click here to read eval($WAF); whitepaper.

Every website is a target; hacktivism

As stated in previous blog posts, hackers don’t just hack websites to steal online databases and credit card details.  Hacktivism, where innocent websites are defaced from malicious users to transmit their political view or opinion, is on the increase.  In many major world political events, online criminals have a great chance to try and gain more victims.

The presidential election protest in Iran, has already led to a range of hacktivism attacks against innocent websites, like the Oregon University System’s website.  The university’s website was defaced for about 90 minutes, and all visitors were redirected to a hacker controlled website, who posted a message criticizing the protests in Iran.  The message included insults aimed at US President Barack Obama, and made depreciatory comments about Iranian opposition leader Mir Hossein Mousavi.

The redirect didn’t harm visitors’ computers, or transfer any malware or viruses.  Still, such attack against your website can cost your business a good fortune, due to down time and bad reputation.  So, whatever the type of online audience your business has, it is always important to secure websites and web applications, as they are always a target!

How to check web applications for SQL injection vulnerabilities

In a previous post, we linked to an article which gave an in-depth explanation of SQL injection vulnerabilities, and what impact such vulnerabilities can have on your web application.  Now, that you know what they are and what their impact could be, how can you find out if your website is vulnerable to SQL injection attacks?

Checking for SQL Injection vulnerabilities involves auditing your website and web applications. Manual vulnerability auditing is complex and very time-consuming. It also demands a high-level of expertise and the ability to keep track of considerable volumes of code and of all the latest tricks of the hacker’s ‘trade’.

Click here to read why an automated heuristic web vulnerability scanner such as Acunetix WVS, is a better solution than a signature-matching solution for detecting SQL injection vulnerabilities on your website or web application.

U.S. Dept. of Defence publishes attack details of two successful U.S. Army web servers breaches

Department of Defence and other investigators, are investigating two U.S. Army web server breaches which were never publicly disclosed.

On 19th September 2007, and 26th January 2008, a Turkish hacker group known as “m0sted” successfully probed 2 U.S. Army web servers, by running a SQL injection attack against the web servers, which exploited a security vulnerability in Microsoft’s SQL Server database.

As a result of such hacks, users trying to access Army Corps of Engineers’ servers or McAlesters Munitions plant website, were redirected to other sites, such as www.m0sted.net.

If these web applications were properly audited with a web vulnerability scanner which can easily identify a SQL injection vulnerability, such as Acunetix WVS, such incident could have been easily avoided.  Proper user input sanitization is a MUST.  Once a website is available online, the web server port is wide open and the only hope one has is that all visitors play fair.  From the above, we can learn that if a website is vulnerable, a malicious user can easily gain access to the rest of the network.

Click here to read more about these breaches.

Acunetix on Twitter

We have create a twitter account for Acunetix. We plan to use this for announcements, as well as product release notifications.

Follow us on Twitter http://www.twitter.com/acunetix

Why File Upload Forms are a major security threat

File upload forms, nowadays can be found allover the internet.  In social network web applications, such as Facebook and Twitter, in blogs, forums, e-banking sites, YouTube and also in corporate support portals, to give the opportunity to the end user to efficiently share files with corporate employees.  Users are allowed to upload images, videos, avatars and many other types of files.

Though, the more functionality provided to the end user, the greater is the risk of having a vulnerable web application and the chance that such functionality will be abused from malicious users, to gain access to a specific website, or to compromise a server is very high.

The following white paper, talks about a number of common security issues and vulnerabilities encountered while auditing file upload forms in several well known web applications.  It also explains how to build secure file upload forms.

You can read this whitepaper from here

New Acunetix WVS Version 6.5 sets new standards in web vulnerability scanning

We are proud to announce the launch of Acunetix Web Vulnerability Scanner Version 6.5.  With this new version, we introduced the new ‘file upload forms vulnerability checks’.  Acunetix is the industry’s first and only Web Vulnerability Scanner to scan web applications for this type of vulnerabilities.

Read more about Acunetix and Version 6.5 release in this press release
Check out the FREE Version of Acunetix WVS V6.5 from here
Download the Acunetix WVS Version6 manual from here

The new features of Version 6.5 are:

• New Login Sequence Recorder, supports more authentication forms and web technologies.
• Session Auto Recognition module; the crawler will identify when a logged in session is invalided or expired and re-logins automatically.
• Actions drop down menu; for each highlighted node, the actions drop down menu is activated showing all possible functions.
• Much more JSP, Java and Tomcat checks and alerts

We also achieved the below major improvements with this version:

• Improved cookie management and session handling to support modern dynamic websites.
• Port Scanner and Network Alerts results appear as a separate node from the web alerts in the results view.
• Ability to import settings from Version 6 installation.
• Added Blind SQL injection timing test using MySQL’s sleep and MS SQL’s waitfor function.  This will help in discovering particular blind SQL injections that do not report a change on the page.

Implementing a web application firewall only is not enough to secure web applications

As demonstrated during an OWASP Europe 2009 presentation, WAF’s (web application firewalls) also have vulnerabilities.  Sandro Gauci (founder and CSO for EnableSecurity) and Wendel Henrique (member of SpiderLabs) showed how an attacker can easily identify and bypass several well known web application firewalls using XSS (Cross site scripting) attacks, the same types of exploits WAF’s should be protecting web applications from.  WAF’s can now be exploited using automated tools, to gain direct access to a web application.

As Wendel Henrique explained, a WAF can help, but securing web applications is much more important.  Apart from that, implementing a WAF can cost a lot of time and money, and there is also the need to make network configuration changes.  On the opposite, scanning a web application with a web vulnerability scanner such as Acunetix WVS, helps you secure your web application without the need of web security expertise, and it saves you time.

Therefore as a conclusion, we can see that although a WAF adds an extra layer of protection, one should never rely on web application firewalls only, and should always ensure that web applications are secure.

You can read more about the OWASP Europe 2009 presentation on Web Application Firewalls vulnerabilities from the following link: http://www.darkreading.com/security/app-security/showArticle.jhtml?articleID=217400819&cid=RSSfeed

Acunetix WVS Version 6.5 BETA is available for download

Acunetix is proud to announce the launch of the BETA version of the upcoming Acunetix WVS Version 6.5.

With this latest version, Acuntix is launching a new set of checks which check for vulnerabilities in file upload forms.  To date, Acunetix WVS Version 6.5 is the only vulnerability scanner which tests websites and web applications for such vulnerabilities.  Such tests can take place even when not using AcuSensor Technology, but when such technology is enabled, the results are more comprehensive whilst reporting less false positives.

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

The new features of Version 6.5 are:

• File upload forms vulnerability checks
• New Login Sequence recorder; supporting much more authentication forms and web technologies
• Session Auto Recognition: during crawling, if the session is invalidated or logged out, the scanner will automatically replay the login sequence without the need for manual intervention
• Much more checks and alerts for JSP, Java and Tomcat web server
• Actions drop down menu; for each selected node, the actions drop down menu is activated showing all possible functions

We also achieved some major improvements with Version 6.5:

• Improved cookie management and session handling to support modern dynamic websites
• Port scanner results will appear as a single node in the results tree
• Users can import their settings from version 6 to version 6.5.
• Added blind SQL injection (timing test) using MySQL’s sleep and MS SQL’s waitfor functions.  This will help in discovering particular blind SQL injections that do not report a change on the page.

Please send your feedback or bug reports to beta@acunetix.com

The Free edition of Acunetix WVS Beta Version 6.5 can be downloaded from here.

Looking forward to hearing from you!

Learning from other's mistakes: Twitter Security

Unless you have been sleeping under a stone for the past four years then you must have heard about Twitter in some way or another. The original idea behind Twitter was to provide a social network where everyone can tell followers what he or she is up to. The only restriction with Twitter is that each message has to be 140 characters or less.

Most times it makes little sense to implement high security features for services that do not deliver sensitive content. The original concept behind Twitter was to simply deliver short text messages with little value and at first glance, a Twitter account does not seem to have much value. Twitter accounts are free and the only information that you send out using Twitter is supposed to be small talk (eg. “Made lemon vanilla cupcakes with..”).

However it didn’t take too long for politicians, organizations and consultants to start using it in their marketing strategies or as a way to stay in touch with a large number of people. Whenever a well known media personality joined Twitter (such as Oprah), a large number of fans would follow. As people and organizations started relying on the service more and more, Twitter’s value increased, while the level of security did not change much. During the US presidential elections, politicians used Twitter as a way to quickly update the public about the latest news. Some people might also exchange information that is sensitive in nature by making use of the private message feature. There are also payment methods that rely on Twitter such as Twitpay and Tipjoy. Twitter was never meant to be used as a payment service, yet people started creating ways to do just about that.

When security is given little importance from the start, web applications have a tendency to have vulnerabilities. In the recent months, Twitter has taken quite a beating when it comes to security. The service has been host to worm attacks, spammer and malware content. What sorts of vulnerabilities were exploited.

Earlier this month, a large number of Twitter accounts started linking to a particular website (StalkerDaily). The reason? A worm was making use of a cross site scripting (XSS) vulnerability in Twitter. The vulnerability was in the account settings page, where victim browsers could be forced to update their profile URL to include javascript code within their page. This javascript code would then do its job as a worm and attempt to infect new Twitter users who visit the infected profile. The vulnerability appeared to be quite a standard XSS security flaw. Even when Twitter said that they initially fixed the flaw, new rounds of a modified worm were infecting Twitter users.

XSS worms were not the only problem that Twitter faced. Some accounts on Twitter have more value than others, such as Barak Obama’s or Britney Spear’s twitter account. When these high profile accounts were compromised, the attackers could reach thousands and millions of followers and send them ‘funny’ messages as well as link to malicious code. These high profile accounts were compromised due to a weak password used by Twitter’s own support.

Then there are attacks that many other popular services are vulnerable to. Phishers have been known to target Twitter accounts where people receive direct messages on twitter linking to web pages that appear to be a Twitter login screen. When it comes to encryption, Twitter still does not enforce encryption by default. Even if one chooses to use HTTPS instead of HTTP, Twitter is still vulnerable to Surf Jacking and similar attacks that can downgrade an HTTPS session to HTTP and allow attackers to hijack Twitter accounts. Finally, spammers have acknowledged the value of Twitter and started using it as another platform to conduct their unsolicited “business”.

One lesson that we should have learnt by now is that for services, such as Twitter, that have potential for growth, security becomes an issue sooner or later. If it is not taken seriously from the start, then it will be much more expensive and generally harder to implement security once the service has taken off. In the case of the XSS worm, the vulnerability appears to be a classic XSS. Such vulnerabilities could be easily found through both automated testing and manual approaches. It would be a mistake to assume that such a web service only needs to be tested once. Websites, especially social networks are dynamic, alive and constantly changing. Any code or feature updates can introduce new security flaws and therefore periodic security reviews are required if such a service is to take security seriously.