In the past, I've talked about some commonly-overlooked Weaknesses you don't want to miss in standard Web Applications. The time is right to cover the same topic in a new context: rich Internet applications. As with most things IT-related, the more complex the application the more complex (and critical) the security vulnerabilities become. Here are some issues I often come across when testing these applications:
- Flash cross-site scripting
Many people think of Flash as a cutesy marketing tool. As with any other code, Flash, can contain exploitable vulnerabilities. Using a free tool such as OWASP's SWFIntruder and HP's SWFScan you can uncover cross-site scripting and more as shown in Figure 1:
Figure 1 – Using HP's SWFScan to uncover XSS in Flash files
Use these free Flash scanners to your advantage because you never know what they're going to find. For example, here's an interesting story about how decompiling Flash code, revealed the logic behind a Flash-based online game that could be exploited and used as a "cheat" to milk a business of its giveaways.
- Weak Flash configurations
Starting with the Flash Player 7 Framework, the crossdomain.xml policy file was introduced which allows for Flash content access across domains. The problem is that if the cross domain policy is configured to allow access from any domain, it can lead to the recovery of cookies and facilitate cross-site request forgery (XSRF) attacks. An example of a weak crossdomain.xml configuration is:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy blah, blah, blah>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>
Rather than allow access from all (*) domains, this file should specify only the domains that need access.
- Web service SQL injection
Web services are those long forgotten souls of Web applications, but they can have vulnerabilities just as any other part of the system. SQL injection is probably the most common issue I see. The following HTTP request and HTML responses using the Web Services Scanner built into the Acunetix Web Vulnerability Scanner product shows what can happen:
HTTP Request
POST /acuservice/service.asmx HTTP/1.0
Accept: */*
Content-Type: text/xml
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Host: testaspnet.acunetix.com
Content-Length: 549
Connection: Close
SOAPAction: "http://tempuri.org/GetUserInfo"
Expect: 100-continue
Pragma: no-cache
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:m0="http://tempuri.org/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<GetUserInfo xmlns="http://tempuri.org/">
<username>' or 1=1 -- </username>
<password>1</password>
</GetUserInfo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
HTML Response
falseSELECT * FROM users WHERE username='' or 1=1 -- ' AND password='c4ca4238a0b923820dcc509a6f75849b'0bladebogdan calin2009-06-02T16:50:00.4671234512345 address
Sure, it can be tricky for malicious attackers to enumerate web services, so that can help, but security by obscurity is never foolproof. Check your Web services for security vulnerabilities too.
- Application availability issues
I've seen several rich Internet applications brought to a crawl by running a simple Web vulnerability scanner against them, and that's just from one host. What if you have dozens, hundreds, or thousands of users connecting at the same time. Application availability and denial of service testing is something you can't overlook. Depending on usage patterns, how your application interacts with users, and specific coding logic you could defy logic and very well increase the load on your server(s) with AJAX and other rich content. Once you hear about slow response times it may be too late to be able to provide a quick fix – especially if you have an intentional denial of service situation taking place.
Using a tool such as the N-Stalker Web Application Security Scanner Load Tester you can record macros for accessing the AJAX and related components of your application and then check for specific response times and transfer rates as shown in Figure 2:
Figure 2 – Using N-Stalker's Load Tester tool to test application load weaknesses
There are other dedicated application stress testing tools such as WAPT and NeoLoad if you want to dig deeper into this area. However you go about it, the important thing is to not ignore application availability issues.
Never lose sight of the fact that no matter how much security testing, scanning, and hacking you do, odds are you won't uncover every weakness – especially at first. Rich Internet applications are just too complicated. As your applications become "richer" so will the security flaws. This highlights the importance of checking these applications on a periodic and consistent basis. Not only will you get better at finding the flaws that matter but the tools you use will mature and be able to root out more of these rich vulnerabilities.
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at www.principlelogic.com.
