http://www.whitehatsec.com/home/index.htmlWhiteHat Security Articles blogenmarketing@whitehatsec.comCopyright 2006 WhiteHat Security [whitehatsec.com]2006-11-30T14:09:30-08:00 hourly 1 2000-01-01T12:00+00:00 Mon, 12 Mar 2007 11:53:16 -0700marketing@whitehatsec.comWhiteHat Security publication2006-11-30T14:09:30-08:00http://www.whitehatsec.com/home/resources/articles/files/myth_busting_ajax_insecurity.html#unique-entry-id-8http://www.whitehatsec.com/home/resources/articles/files/myth_busting_ajax_insecurity.html#unique-entry-id-8
AJAX (Asynchronous JavaScript + XML) is a combination of web browser technologies that allows web page content to be updated “on-the-fly” without the user moving from page to page. In the background of an AJAX-enabled web page, data (typically formatted in XML, but also HTML, JavaScript, etc.) is transferred to and from the web server. In the case of Gmail, new email messages are displayed as they arrive automatically. In Google Maps, a user may mouse-drag through street maps without visiting additional pages. The mechanism for performing asynchronous data transfers is a software library embedded in all modern web browsers called XMLHTTPRequest (XHR) . XHR is the key to a website earning the “AJAX” moniker. Otherwise, it’s just fancy JavaScript.

If you’re thinking that none of this sounds security related, you’re right. AJAX technology makes website interactivity smoother and more responsive. That’s it. Nothing changes on the web server, where security is supposed to reside. If that’s the case, then what is everyone talking about? Word on the cyber-street is that AJAX is the harbinger of larger attack surfaces, increased complexity, fake requests, denial of service, deadly cross-site scripting (XSS) , reliance on client-side security, and more. In reality, these issues existed well before AJAX. And, the recommended security best practices remain unchanged. If you’re like me, you want to know what’s really important, so let’s take a closer look.



Does AJAX cause a larger “Attack Surface”? No.

The term “Attack Surface” applies to a concept used to measure security by analyzing the points in a system that are open to attack. For software, these points are areas of data input and output that can be manipulated by a third-party. Obviously the smaller attack surface an application has, the easier it is to secure. What’s also obvious is that web applications, or any application, only have as much functionality (attack surface) as has been programmed in. It doesn’t matter if the user interface uses AJAX, Flash, ASCII art, or anything else. Again, AJAX is a web browser (client-side) technology. It does not execute on the server. While the coolness factor of AJAX drives developers to publicly expose more functionality - which may introduce new “server-side” vulnerabilities - this can hardly be blamed on AJAX. New code has always meant an increased risk of vulnerabilities.

Furthermore, in my experience, AJAX-enabled web applications are no more functionally complex than standard web applications. Google Maps is actually a less sophisticated application than the seemingly simple craigslist. Gmail is less complex than Outlook Web Access. Also, web applications (re)-designed using AJAX stand a better chance of being developed on more up-to-date platforms (.NET, J2EE, etc). These platforms are inherently more secure and less prone to vulnerabilities such as SQL Injection, Credential Session Prediction, Directory Traversal, and a dozen other common threats than previous generations.


Does AJAX make the “Attack Surface” harder to find? Yes and No.
A corporate security program is incomplete without measurable results. The most common way to measure the security of a website is by simulating attacks--thousands of them (i.e. a vulnerability assessment). A vulnerability assessment can be performed either manually, or with an automated scanning tool, or preferably with a combination of the two. One of the first steps in the process is to locate input points in the web application, or the “attack surface.” Therefore, a complete vulnerability assessment requires finding them all.

Automatically crawling the entire website and mapping the links is standard practice. This method works fine on some websites, others not at all, and the rest fall in-between. The challenge is that new websites often utilize heavy JavaScript, Flash, ActiveX, Applets, and AJAX, where links are either buried or dynamically generated within complex client-side code. Parsing out these links is often hard and sometimes impossible. Therefore automated scanning becomes increasingly less reliable as a method for validating the security of an AJAX enhanced website.

Humans on the other hand have an easier time sifting through code and inferring relationships. Many times the JavaScript source documents all the areas of input into the website, almost like an XML web service, which is useful not only for the good guys, but for the bad guys as well.

In a normal website, there would be no such resource and an assessor must rely on link crawling. The conclusion is that AJAX doesn’t make websites less secure, but it can make them more challenging to assess.


Can AJAX cause “Denial of Service”? Not really.
It has been claimed that AJAX-enabled websites utilize an application design in which a larger volume of smaller HTTP requests are used as opposed to fewer, larger requests. For instance, Google Suggest may fire off a tiny HTTP request for each user keystroke in an attempt to perform automatic word completion. The assumption is that if there are 1,000 users on the system, moving to the AJAX rapid-fire model will exponentially increase the number of requests to the system. This could potentially result in a denial of service (DoS) scenario. I suppose this is possible, but whose fault is this really?

In my view, this problem is not caused by AJAX or even a bad software design strategy, but instead by a lack of proper implementation and performance testing. The solution is to tune the configuration or add more web servers. And to be realistic, if someone wanted to DoS a network, they could flood the network with HTTP traffic whether AJAX was used or not.


Does AJAX rely on client-side security? No.
OK, let’s return to web application security 101. Web applications must NEVER trust the client (web browser). This is gospel whether the web page interfaces use JavaScript, Flash, ActiveX, Applets, AJAX or any other protocol or language. Every developer should be aware that basic HTTP proxies may alter anything about the HTTP request, even those generated by XHR. Great care should be taken to ensure that all security checks are performed on the server--no exceptions.

Does this mean that security professionals should not use client-side security checks? No, quite the opposite. I actually recommend using client-side security in forms and other business process flows because it benefits the user experience by being more responsive. There’s no need for a round trip to the server to inform the user that he’s typed a letter into the phone number field. This also lessens server load by pushing some processing time onto the client.


Does AJAX lead to poor security decisions? Sort of.
The new Web 2.0 websites often include data from one or more third-party websites, creating something known as a “mash-up.” AJAX developers would prefer the user to pull in the data directly from the third-party, thereby reducing bandwidth; but, this is not possible with XHR technology. XHR has security protections built-in, preventing a user’s browser on Website A from making connections to Website B. This helps protect users from malicious websites, where JavaScript Malware on the page could force a user to download all your bank account information. Web developers, not wanting to stifle innovation, created a work around to enable access to third-party sites.

What developers often do is create a local HTTP proxy on the host web server. To have the client pull in data from a third-party website, they’ll direct an XHR request through the local proxy pointing to the intended destination. Consider the following example request generated by the web browser:

http://websiteA/proxy?url=http://websitesB/

Website A takes the incoming request. The “proxy” web application then sends a request to Website B designated by the “URL” parameter value. With the proxy, developers can use XHR to make off-domain requests. And since XHR won’t send the user’s authentication cookies to Website B, because Website A did not connect to it directly, it is safe for them as well. The security issue is that Website A is hosting an unrestricted HTTP proxy.

Attackers love finding open proxies because they can initiate attacks that cannot be traced to their origin. The capabilities of the proxy should be carefully controlled and restricted with regard to which websites it will connect to and how. In my opinion, the problem lies with developers circumventing security controls without adding appropriate safeguards, not AJAX.


Does AJAX make Cross-Site Scripting (XSS) attacks worse? I hope not.
Can it get worse? During my presentation entitled “Hacking Intranet Websites from the Outside” at BlackHat 2006, I demonstrated how JavaScript Malware is able to acquire internal NAT’ed IP addresses, port scan, blind web server fingerprint, steal browser history, and exploit web-based interfaces on an intranet. The Washington Post called it “disturbing.” All proof-of-concept code was achieved without AJAX, just plain old JavaScript.

XHR can initiate just about any desired HTTP request - provided the request remains on-domain - and view the response. Plain JavaScript can make the same requests, without the on-domain limitation, but can’t typically view the response. This means if a user is on Website A, XHR cannot force user connections and read data from Website B. However, plain JavaScript could. If you look at it that way, XHR (AJAX) is more secure!

AJAX has fired up interest in JavaScript. Research in JavaScript has led to new malware discoveries whose potential severity is amplified by ubiquitous XSS vulnerabilities. To be fair, the Samy Worm that hit MySpace and JS-Yamaner on Yahoo exploited XHR for propagation. However, the attack could have just as easily been perpetrated using plain JavaScript. AJAX is irrelevant in this scenario. What matters is finding and fixing XSS vulnerabilities in web applications. The WhiteHat Security white paper “Cross-Site Scripting Worms and Viruses” is an additional information resource.


Does AJAX change security best practices? No.
If a web application has vulnerabilities, it will be insecure no matter what techniques are used to develop it. If a web application is well designed, no amount of “insecure AJAX” will reduce its security posture.

Following are five tips for securing Web applications:

1) Secure by design. Start secure and stay secure by including security as a component in each stage of the software development lifecycle.
2) Rock-solid input validation. Never trust the client, ever.
3) Use reliable software libraries. From encryption to session management, it’s best to use components that are tried and thoroughly tested. No need to reinvent the wheel and repeat the mistakes of others.
4) Secure configuration. Every component of the website should be configured with separation of duties, least privilege, unused features disabled, and error message suppressed.
5) Find and fix vulnerabilities. Continuous vulnerability assessments are the best way to prevent attackers from accessing corporate and customer data. You can’t control what you can’t measure.

Following these best practices is the first step. Validation is the second. No company can be expected to write flawless code, or have staff available around-the-clock to address all its Web application vulnerability issues. That’s why WhiteHat created WhiteHat Sentinel, a continuous vulnerability assessment and management service for web applications. WhiteHat Sentinel is available 24/7, enabling companies to identify, prioritize and ultimately remediate the vulnerabilities that leave web applications open to attack.

Remember the fundamentals, use defense-in-depth, and your online business will be safer.

About the Author
Jeremiah Grossman, founder and chief technology officer of WhiteHat Security, is a world-renowned expert in web application security and a founding member of the Web Application Security Consortium (WASC). At WhiteHat, Mr. Grossman is responsible for web application security R&D and industry evangelism. He is a frequent speaker at industry events including the BlackHat Briefings, ISACA's Network Security Conference, NASA, ISSA and Defcon. A trusted media resource, Mr. Grossman has been featured in USA Today, the Washington Post, Information Week, NBC Nightly News, and many others. Mr. Grossman is also a featured expert and frequent contributor on TechTarget's SearchAppSecurity.com. Prior to WhiteHat, Mr. Grossman was an information security officer at Yahoo!


About WhiteHat Security, Inc.
Headquartered in Santa Clara, California, WhiteHat Security is a leading provider of web application security services. WhiteHat delivers turnkey solutions that enable companies to secure valuable customer data, comply with industry standards and maintain brand integrity. WhiteHat Sentinel, the company’s flagship service, provides continuous vulnerability assessment and management for web applications. For more information about WhiteHat Security, please visit our website, www.whitehatsec.com.
]]>marketing@whitehatsec.comWhiteHat Security publication2006-09-29T09:10:46-07:00http://www.whitehatsec.com/home/resources/articles/files/971371291788b8fe64f22695e97844fe-6.html#unique-entry-id-6http://www.whitehatsec.com/home/resources/articles/files/971371291788b8fe64f22695e97844fe-6.html#unique-entry-id-6
The disconnect comes from a common misunderstanding of where, when, and how buffer overflows are exploited. A buffer overflow is a software condition in which an application attempts to store more data in a memory buffer than has been allocated. The overflow will overwrite adjacent memory, which could cause the application to crash. Cleverly designed buffer overflow exploits are able to take advantage of this situation by overwriting specific pieces of memory to execute arbitrary system commands and take over computers. The nature and origin of buffer overflows has been covered exhaustively in numerous articles and white papers . And, we’ve all seen the result of well-executed buffer overflow exploits on corporate networks.

Normally, buffer overflow vulnerabilities are found through source code analysis, or by reverse engineering application binaries. Depending on the instance, a person could spend hours, weeks, or even months stringing together memory addresses in order to create functional exploit code. For hackers to uncover these issues, they really need to get their hands on the running application. The hacker can then repeatedly exploit the buffer overflow, capture the crashed application state (via SoftIce or Gnu Debugger) and trace the buffer through



memory. This is why buffer overflows usually appear within compiled commercial and open-source software, rather than in custom web application code.

Custom web applications are exactly that ⎯ custom software that an organization develops for itself and hosts on its web servers. We’re not talking about commercial Web software components from IBM, Microsoft, or SAP. This means that the public, including hackers, is unlikely to have access to the application source code or essential elements for testing. As a result, the way buffer overflow vulnerabilities are identified and possibly exploited in custom web applications is a completely different process. With the exception of a source code review, testing a web application for buffer overflow vulnerabilities must be performed remotely over the network.

Penetration-testers, as well as hackers, do not have access to source code, application binaries, or memory dumps. Testing is blind. A typical test will input several thousand characters into a URL query string parameter (Example 1.) and wait for the web server to respond with a “500” error response code (Example 2.). A 500 code may be an indication that an application has crashed server-side due to a buffer overflow, but this is extremely unlikely. It is more often the case that a device in the connection chain, including web application firewalls, http proxies, load balancers, web servers, application servers, or others, caught the abnormal test and returned an identical 500 error message. This is why blind buffer overflow tests are prone to heavy false-positive rates. The fact is that anything could have caused a 500 error, but only rarely is it a web application buffer overflow.

Example 1.

http://webserver/foo.cgi?param1=AAAAAAAAAAAAAAA….5000 A’s




Example 2.




However, if a buffer overflow did exist, it would likely be in common off-the-shelf components used to build the website, such as Microsoft IIS, Apache, Oracle, MySQL, SiteMinder, and thousands of others.

In order to further understand why buffer overflow exploits do not normally occur in custom web applications, consider this hypothetical, and rare, situation: a hacker wants to perform a buffer overflow exploit and nothing is restricting user-supplied input to a custom web application. What needs to take place for the attack to succeed?

In the simplest of circumstances, the hacker would have to find a vulnerable web application and parameter, discover the size of the buffer, properly overwrite the stack pointer, and load in well-written shell code . And, all of this must be done while completely blind to any application or CPU architecture specifics. Call me jealous, but you’d have to be one of those Hollywood movie hackers to pull this off. It would be like swishing a basketball blindfolded while standing outside in the stadium parking lot. Perhaps this is why the Web Application Security Consortium (www.webappsec.org) has yet to identify a single media reported incident where a website was hacked due to a buffer overflow within a custom web application.



There is another critical aspect to consider when evaluating the risks of buffer overflows in custom web applications. Popular web application programming languages , such as Java, are immune to buffer overflows by their very nature. These languages perform their own memory handling and unless there is some problem with the interpreter (rare), you’re safe. So if someone alerts you to a buffer overflow in your web application, you have every reason to be skeptical, especially if you are using one of these languages. Let me be careful here to say that I’m not suggesting we have carte blanche to leave our code riddled with memory handling issues. In fact, if you’re using a C/C++/C# language or variant, and you do happen to be vulnerable, then maybe there is some risk worth investigating.

So the real source of the disconnect between real-world findings and the OWASP top ten is risk evaluation. We agree that IF someone managed to exploit a buffer overflow in a web application, then it would result in a critical situation. However, businesses need to prioritize their risk based on the likelihood of occurrence and focus on those vulnerabilities/issues most likely to be found and exploited by hackers. The question is, what exactly are they?

My advice is that to get the most bang-for-your-security-buck take care of your Cross-Site Scripting (XSS) and SQL Injection vulnerabilities, Authentication/Authorization loopholes, and business logic flaws. These are the vulnerabilities worth going after first because they significantly reduce risk. To defend against these threats, assess early and assess often to protect sensitive data and stay out of the headlines.


About the Author
Jeremiah Grossman is the founder and Chief Technology Officer of WhiteHat Security (http://www.whitehatsec.com), where he is responsible for web application security R&D and industry evangelism. As an industry veteran and well-known security expert, Mr. Grossman is a frequent international conference speaker at the BlackHat Briefings, ISSA, ISACA, NASA, and many other industry events. Mr. Grossman's research, writings, and discoveries have been featured in USA Today, VAR Business, NBC, ABC News (AU), ZDNet, eWeek, and BetaNews. Mr. Grossman is also a founder of the Web Application Security Consortium (WASC), as well as a contributing member of the Center for Internet Security Apache Benchmark Group. Prior to WhiteHat, Mr. Grossman was an information security officer at Yahoo!, responsible for performing security reviews on the company's hundreds of websites.

Originally published on SearchAppSecurity, March 2006.


]]>marketing@whitehatsec.comWhiteHat Security publication2006-05-23T12:45:03-07:00http://www.whitehatsec.com/home/resources/articles/files/c91b8015260b2e3cf572a95033d4a9b8-5.html#unique-entry-id-5http://www.whitehatsec.com/home/resources/articles/files/c91b8015260b2e3cf572a95033d4a9b8-5.html#unique-entry-id-5On November 11th, 2003, the chess-playing machine X3D Fritz tied grandmaster and former world champion Garry Kasparov in a four-game match. In this classic contest of Man vs. Machine, X3D Fritz performed so impressively that the game was heralded as a victory for artificial intelligence. X3D Fritz’s powerful play was achieved by calculating millions of moves per second accompanied by gigabytes of stored positions. Each time Kasparov moved a chess piece, X3D Fritz would analyze the board by drawing upon its vast knowledge base to select the best possible move. So what do chess, the world’s most dominant computer chess machine, and Garry Kasparov have to do with web application security?

For many years, security professionals have thought that there would come a day when technology alone could identify all web application vulnerabilities and prevent all attacks, eliminating the need for the Kasparovs of the world. What we’ve come to understand is web application security is a fundamentally different game than chess, or even network security. It’s highly unlikely that machines will ever replace man completely in the process of assessing website security. What’s important to understand is why.

Chess is a straightforward game. The board presents a finite number of legal moves and a limited amount of end-game positions. With chess it’s mathematically possible to calculate every move that may result from a given position and further “n” moves into the future. Since the game itself is defined and finite, although granted extremely large, the path to victory can be completely automated and followed precisely. Eventually computers will win at chess every time rather than settling for a tie. Websites are at the opposite end of the spectrum. They maintain an open door policy with regard to user interaction, rarely following Internet standards, and never operate the same way twice. Simple tasks such as shopping online or web banking are drastically different functionally and architecturally. Web application vulnerability scanners operate in a complicated environment where the end result of a process is anything but obvious.

Web application vulnerability scanners depend on the relative predictability of websites to identify security issues. Using a loose set of rules, scanners function by simulating web attacks and analyzing the responses for telltale signs of

weakness. From experience, we know how a website will normally react when there is a security issue present. We know that if sending a website certain meta-characters produces a database ODBC error message, a SQL Injection issue has likely been detected. At WhiteHat Security we call these “technical vulnerabilities” and scanners have become fairly proficient at identifying them. But as websites become increasingly sophisticated, yesterday’s telltale signs are today’s false-positives. As such, we’re not guaranteed that a specific result necessarily indicates that a security issue is present. This has made the automated process of finding simple vulnerabilities hard, and finding difficult ones impossible.

Consider the following example. If we visit a website and are presented with the following URL:

http://example/order.asp?item=50&price=300.00

Can we guess what the application order.asp combined with the parameters item and price do? Using intelligence unique to humans, we can quickly deduce their purpose with relative certainty. This is a product ordering application. The item parameter is the particular product we are interested in. In our case, let’s say an iPod. The price parameter is the amount we are going to pay for our portable music player. What happens if we changed the price of 300.00 to 100.00? Or 1.00? Does the website still sell us the iPod? If so, we can easily understand that the website should not have allowed the price alteration. As humans, we possess a natural ability to assess context, and we aptly refer to these types of issues as “logical vulnerabilities,” issues that only humans can identify.

Now, if an automated scanner attempted the very same attack in a generic fashion, how would it decide if a custom website’s response were good or bad? How would it know if the attack worked or was adequately defended? Or what the item and price parameters were supposed to do in the first place? The answer is clear: scanners cannot reliably make these assumptions. The numbers in the URL easily could have meant something else entirely when presented in a different context. The rules for what is supposed to happen on website are not defined as they are in chess. These decisions require contextual knowledge of the system, plus the ability to “logically” understand any number of previously undefined results.

In mathematics, this very large obstacle is commonly referred to as the undecidable problem . An undecidable problem is a problem that cannot be solved for all cases by any algorithm (or computer program). Chess IS NOT an undecidable problem since it can be accounted for in all instances at all times. Fully analyzing custom web application software for vulnerabilities IS an undecidable problem. That’s why the game of chess can be fully automated by a computer and identifying vulnerabilities in custom web applications cannot be.

There are unique aspects of the human mind that computers have yet to duplicate. WhiteHat’s statistics, based on aggregate data from thousands of assessments, indicate that only about half of the possible web application security issues can be tested for in a completely automated fashion. The remaining tests for logical issues require the involvement of a web application security Garry Kasparov.

In a thorough web application security assessment, potentially hundreds of thousands of customized tests must be performed. By hand, even the world’s best experts would never be able to complete this much work in a feasible amount of time. Similar to the work of X3D Fritz, harnessing the power of a truly enterprise class vulnerability scanner greatly deceases the workload by performing the monotonous tasks that can be automated. Scanners are great at tackling technical vulnerabilities such as Cross-Site Scripting and SQL Injection, and not effective at identifying price list modification, Credential/Session Prediction , and Insufficient Authorization . By understanding these concepts, the industry has acknowledged that the pairing of an experienced security expert with a scanner is a best-practice for achieving complete vulnerability coverage.

To build this program our customers use WhiteHat Sentinel, a
turnkey approach to continuous website vulnerability assessment and management. WhiteHat Sentinel provides a comprehensive, consistent, and efficient testing methodology backed by experienced professionals. While artificially intelligent computers like HAL 9000 may arrive or someone may achieve the mathematical breakthrough of the century, currently technology alone is no match for the human mind.





]]>marketing@whitehatsec.comWhiteHat Security publication2005-09-29T09:23:56-07:00http://www.whitehatsec.com/home/resources/articles/files/806a7c56ef2621a24d303799fe4fd577-7.html#unique-entry-id-7http://www.whitehatsec.com/home/resources/articles/files/806a7c56ef2621a24d303799fe4fd577-7.html#unique-entry-id-7*Names have been withheld or changed to protect the innocent

As the CTO of a web application security service company (http://www.whitehatsec.com), much of my time is spent educating companies on how to reduce the risks of conducting business online. Most of the people I speak with are stunned to learn that nine out of ten websites contain vulnerabilities. Think about it. Every time you visit your favorite online store, check your account balance or participate in a chat, there’s a 90% likelihood that the site can be compromised in some way. Despite the statistics, many IT/security professionals still believe that firewalls and SSL can protect their web applications, or that their developers write perfect code. Whatever the reason, many organizations will learn the hard way that web applications are the new point of entry into their systems, by getting hacked. Consider MySpace, the social networking site. Exploitation of a common cross-site scripting vulnerability affected roughly 1 million users and cost 20 hours of downtime. What company can afford that?

When speaking with organizations, WhiteHat is often asked to justify the need for a web application security service, especially on an ongoing basis. IT/Security employees typically request a way to convince those who control the checkbook (management) that web application security is something worth spending time and money on. What we’re really being asked is to demonstrate how someone could hack a company’s website and cause serious harm. In the industry this practice may be referred to as a “penetration test.”

Penetration tests are often used to quickly spot security weak points and compromise a system as fast as possible. The results are far short of a “security assessment” where the review is more exhaustive and the analysis is more comprehensive. Penetrations tests attempt to find and exploit a few vulnerabilities, while assessments identify all the risks. A benefit to those performing penetration tests is that it keeps the skills sharp, improves automation technology, and validates testing methodology. Plus, they’re fun. And having fun as only security people could, at WhiteHat Security we like to race.

As a spontaneous office activity, a few of us will race to find the first and best vulnerability in a never-before-seen website. “Cross-Site Scripting” (XSS) or better is the lower bar we’ve set. Most of the time identification of the first vulnerability occurs in less than two minutes, which adds to the adrenaline rush. The second challenge is to find the first and best high severity vulnerability. Normally high severity vulnerabilities allow you to access someone’s account data, execute administrative level functions, or circumvent important business logic process. These issues take more time to find, although the average is still less time than it takes to have a pizza delivered. At WhiteHat’s office, the prize is bragging rights.

Recently, we penetration-tested a website that hosts thousands of enterprise-level customers. I’m not able to give many details about the exact nature of the system, except to say that it was nothing less than mission critical. Companies depend on the web-enabled service for core business operations. Hacking this website would reveal sensitive information about thousands of diverse company and network infrastructures. It would be a company’s worst nightmare if someone nefarious exploited the system and took control. We were informed that the website had been examined for security issues previously, even scanned, yet nothing questionable was found. Our penetration test was not expected to succeed. As one might expect, there was extreme interest on the client’s part in any security issues we’d find and great anticipation on WhiteHat’s side for the challenge ahead.

This website was built using ASP.NET which you can always identify by the familiar “aspx” file extension. ASP.NET (1.1) makes finding XSS and “SQL Injection” significantly harder because the default configuration blocks special characters in the URL required for exploitation. But on many ASP.NET installations, the security configuration is turned off in certain areas, most likely because the website doesn’t function properly with them. For example Shaquille O'Neal, with the apostrophe (special-character) in his name, might have trouble logging in.

With the necessary paperwork signed and account credentials generated, we were ready to go. The URL and username/password were revealed to the racers and the symbolic green flag dropped. The next several seconds we heard nothing but mouse clicks and keyboard tapping. From past experience we’ve learned that the fastest way to victory is to target the search boxes first and try for a speedy XSS win. Search boxes are notorious for such insecurities. It’s a cheap trick, but it works. Next, it’s best to look for input parameters and determine if any of them echo URL query data, indicating another potential spot for XSS.

The first 60 seconds of the race flew by. Nervousness set in because we knew that at any moment someone was going to claim speed-hack victory. Bill Pennington (WhiteHat’s VP of Services), in what is becoming a trend, identified the first vulnerability (XSS) in about 1 minute 30 seconds. We’re convinced he’s got some kind of bug-finding E.S.P. In classic style, we cried foul because he could arguably only XSS himself and represented no further risk. But the ruling on the field was that the office rules cited no such provisions, thus giving Bill the win. Time to change the rules for next time. Now that the easy stuff was out of the way, it was onto the tough stuff.

Over the next few minutes I found a few other XSS issues of the “Non-Persistent” variety. More severe vulnerabilities than Bill’s find, but I was too slow. The next discoveries were instances of “Information Leakage” and “Predictable Resource Location,” essentially uncovering operating system directory structure and notes on application configuration. Still, nothing worth gloating over. That’s when I fired up my trusty custom proxy, and began clicking around the website while monitoring all HTTP requests for anything interesting.

After ten minutes elapsed, I found a peculiar URL with a parameter name-value pair containing something worth investigating. The URL was hard to spot because it was buried behind a JavaScript enabled link and redirect so it was never directly visible in the web browser. Most of the query data portion of the string was obscured by the URL-encoding format. In the URL there was a distinguishable “AND” with “+” symbols on either side, indicating a possible embedded SQL statement. I decoded the URL to observe it further. Yes, this definitely was a partial SQL statement complete with a “WHERE” clause hiding beyond the immediate view of the location bar. Altering the URL with the usual single-quote semi-colon did not yield anything useful because the code-500 code messages were devoid of the common SQL debug error messages. Good for security, bad for me. I needed an exploit and it had to be done blind.

The rest of the team was silent, but the furious keyboard pounding signaled that it was only a matter of time before someone spotted the same vulnerability or another one sooner. And that’s exactly what happened. Bill, while parameter tampering, was rotating a query string ID value to reveal the names of other customers (~11 minutes). A very respectable “Insufficient Authorization” discovery. Not necessarily a harmless flaw, but far short of a system compromise, so the game was still afoot and I knew I was close.

Simultaneously, I was working on the SQL statement embedded in the URL. The SQL statement appeared to be querying the database while combining it with my account ID (also present in the URL). This was done so that only data paired with my account ID would be returned. After several failed hack attempts, I wondered if I simply swapped the AND for an OR, would everyone’s data fitting the description dump out? I wanted to find out. It took me a moment to understand what I was looking at, but that’s exactly what happened. A SQL Injection exploit and no errors generated (~15 minutes). I was viewing information that should not be available under my user account. In fact, this was direct backend database access system-wide. It was possible to pull up any information I wanted, an unthinkable and unacceptable business risk.
I stopped short of attempting more sophisticated requests because we could already demonstrate solid proof-of-concept. No need to exploit anything further than what was required. At that point the contest was over, Bill won the speed hack, I got the best exploit. At the end of the 15-minute race the team generated about a dozen vulnerabilities ranging from low to high severity.

During our post-op meeting, we described our findings to the client organization. We explained the vulnerabilities, the potential impact, and the available remedies. For the organization, exposure and/or exploitation of the issues we found would have been devastating for them and their customers. Naturally people in this position feel somewhat embarrassed and defensive, especially after claiming the website is solid. They spent a lot of hard hours building the system and no one likes to be told that their baby is ugly. The truth is that there really is nothing to be ashamed of since, as I stated, nine out of ten websites have these issues. The key is to acknowledge that these holes exist, know the vulnerability status on all your websites and fix the issues in a timely manner. With that, you can be the exception rather than the rule.


]]>