Application Security : Unlocking the myth
By Avinash K Tiwari
More and more companies are relying on Web-based applications to provide online services to their employees, to support e-commerce sales and to lever¬age portals, discussion boards and blogs that help staff better communicate with customers, partners and suppliers. However, as the number and complex¬ity of Web applications have grown, so have the associated security risks. With increasing frequency, incidents of Web application breaches resulting in data theft are popping up as front-page news.
Some of news you can’t ignore
World story
• 40 Million Credit Cards Compromised
• 55 Million Customer Records Exposed, 130+ Security Breaches in 2005
• $105 Billion In Cyber crime Proceeds in ’04, More than Illegal Drug Sales
There have been quite a few Govt and FSS security breaches in India recently.
• Hacker breaks into 17 bank a/cs
• Bank of India site hacked, served up 22 exploits
• Maharashtra govt website hacked
• Goa govt’s info website hacked
A fact which can’t be ignored:
Close to 80% of web sites are vulnerable to Cross-site scripting, which can be executed even by a novice hacker. Your website could be one as well.
A myth that our website is safe:
“We have Firewalls in Place”
“We Use Network Vulnerability Scanners”
“we use SSL”
What’s the real picture??
Lets take a look at the different security layers used in the protection of a web application:
In order to protect the desktop, users and organizations install antivirus protection
The communication layer is protected by encrypting the traffic, using SSL
Firewalls and IDS are used to only allow specific communication (port) access (i.e. WEB traffic)
Let’s take each layer one by one
When we talk about web traffic desktop security is not in picture
Using SSL will encrypt the web traffic and make life difficult for a hacker intercepting the traffic. But, use of SSL can’t stop a hacker from manupulating the data by directly accessing the application
Firewalls are set up to allow outsiders access to specific resources, and to prevent them from accessing other resources. For example, an outside individual wouldn’t be allowed to directly connect to a database, but they can make a request to a web server. This means the firewall would be configured to deny traffic on a standard database port 1443, but allow traffic through ports 80 and 443 - web application ports. This system is clearly no protection at all against malicious attacks aimed at the web application.
The next protection an HTTP request encounters is an intrusion detection system. The IDS has been set up to look for signatures in the traffic that might indicate an attack. For example, they may look for a SQL statement embedded within a request, or they might look for a script tag that indicates a potential XSS attack. The challenge with these systems is that if the request is encoded in some alternative format (such as Unicode Transformation Format, UTF-7) or perhaps the traffic is encrypted using SSL, the intrusion detection system is often not able to interpret or understand the requests. The IDS offers little to no protection against the web application attack.
The last system that the HTTP request might encounter before the web server is probably an application firewall. These are the smartest of all the network protections and can be configured explicitly to only allow certain traffic that it knows to be good. The problem with these systems is that it’s very expensive to maintain the correct configurations or valid algorithms and testing of these systems to recognize good traffic. If the web application firewall has been designed to fail securely (a web application security principle), that is, if you’re not sure what to do, they block the user, the web application firewall may block legitimate traffic. For this reason, most application firewalls are usually designed to break one of the founding principles of security (fail securely) by allowing through traffic that they don’t understand.
So, as you can see, even with antivirus, firewalls and IDS, you still have to allow web traffic through your firewalls, IDS and IPS. This web traffic can be friendly, or it could be malicious – but there is no way to know which one it is. Since web users can access your application over the web, they can perform all sorts of malicious activities and either steal, manipulate or destroy information.
So the bottomline is THE WEB APPLICATION MUST DEFEND ITSELF.
(Copyrighted by CresTech Software Systems Pvt. Ltd.)
http://www.qacampus.com
http://www.crestech.in
http://www.crestechsoftware.com.au
Tuesday, May 19, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment