Website Security Whitepaper

Technology Alone cannot Defeat Website Attacks:
Understanding Technical vs. Logical Vulnerabilities

Download a Complimentary Copy of this Whitepaper ›››

On 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, or rather, website 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 website 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. Website vulnerability scanners operate in a complicated environment where the end result of a process is anything but obvious.

The Difference between Technical and Logical Vulnerabilities
Website 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 also 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 very complex, 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 a digital camera. The price parameter is the amount we are going to pay for our digital camera.

What happens if we changed the price of 300.00 to 100.00? Or, 1.00? Does the website still sell us the digital camera? 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.

About the Author ::
Jeremiah Grossman is the founder and CTO of WhiteHat Security. Mr. Grossman is a world-renowned expert in Web security, co-founder of the Web Application Security Consortium, and recently named to InfoWorld's Top 25 CTOs for 2007. He has authored dozens of articles and white papers, is credited with the discovery of many cutting-edge attack and defensive techniques, and co-author of the recently published book, Cross-Site Scripting Attacks. Mr. Grossman is frequently quoted in business and technology publications such as InfoWorld, USA Today, PC World, Dark Reading, SC Magazine, SecurityFocus, C-Net, CSO Magazine, and InformationWeek.

 

 

 

 

 

Website Risk Management  |  Sentinel Services  |  Support Plus  |  Education Services  |  Events & News  |   Resources  |   Partners  |   About WhiteHat
2010 © Copyright  |  WhiteHat Security  |  3003 Bunker Hill Lane, Santa Clara, CA 95054  |  408.343.8300  |  Contact the Webmaster
Facebook YouTube