Building and deploying applications has become a lot easier than it was even five years ago, and it is becoming even easier with quick development toolkits, cloud computing, and Platform as a service (PaaS) environments. However, along with easier application development comes more application flaws, especially with web applications, which can become business liabilities.
The key thing to remember for security of web and network applications is to keep business logic and control on the server side, and the user interface on the client side. Use the metaphor of a store: even if the customer can browse the aisles and bring objects to the check-out counter, all of the “business” happens behind the counter.
An example of what can happen occurred in 2009. Domino’s Pizza had launched a major ad campaign to win customers. Part of the launch included a Flash application on their website to allow customers to order pizza online. The Flash app included a field to enter a coupon to get a pizza for $5. One night, a hacker decompiled the Flash app to look at how it worked, and discovered that it checked the coupon code inside the app. Additionally, he discovered that Domino’s marketing department had planned ahead for a more aggressive coupon: a pizza for free. The coupon code was listed in the Flash app, so he tried it. 30 minutes later, he was enjoying a free pizza. 30 minutes after that, he posted the coupon code into an online forum. By the time Domino’s corporate office opened the next morning and discovered their secret had been released, over 11,000 free pizzas had been delivered. Embedding the coupon code into the client side application had allowed it to be exposed, and cost the company over $50,000 in free pizza. For a large company, that’s not a lot of money, but it was money that could easily have been saved by verifying the coupon code on the server instead.
Similar examples have been found that use a relatively simple substitution of data on a form submission to allow an attacker to set her own price when ordering from a web site. The server sent the web page to the client with prices for each item, but the “add to cart” button submitted the price back to the server. In one instance, a security researcher successfully placed an order for a multi-million-dollar product for the cost of less than one dollar. This kind of flaw would also have been easy to avoid: return the part number from the client, and let the server look it up in the same database it used to list the prices when drawing the page.
Both of these examples assume an e-business model, but application flaws can affect any kind of web application. When an application is flawed it results in network security weaknesses, creating vulnerability. Vulnerability potentially allows an attacker to gain access to system information, or even system configuration. While security threats like Denial of Service attacks are just intended to take a system offline, application flaws can lead to an attacker taking system control.
Unintentionally poor implementation of an application can also leave it vulnerable to attacks like SQL injections. Today, SQL injection attack vectors are the most common form of attack according to the 2012 Verizon Data Breach Investigations Report. A typical scenario for an SQL injection is when an attacker is able to embed SQL control statements into text fields on a web page. When the form is submitted, the SQL server doesn’t just store the text – it recognizes and executes the commands. The results can be severe: recently, in June 2012, over 6 million hashed passwords from LinkedIn were posted online. While LinkedIn has refused to comment officially, an article in SC Magazine cites the claims of anonymous insiders that the hack occurred several months ago via SQL injection. LinkedIn was actually lucky: first, SQL injection could potentially have given an attacker power to delete much of their content. Second, LinkedIn eventually found out about their web app flaw, and should be able to fix it. Compare that to Nortel Networks, who had a data breach that lasted almost 10 years.
Despite its power, a SQL injection flaw is relatively easy to fix. When the web server receives information from the user, it should quote or encapsulate the data in a way that the SQL server will only see it as data, never as an instruction. However, if the web application was written so that each page can connect directly to the SQL server, not through a local function, then the fix will require searching through the entire app to ensure that each SQL connection goes through that local function which applies the security controls. It’s a lot less painful to include security at the design phase than trying to retrofit it in later.
Although all of the examples in this blog post have been big, most companies are small, and a recent survey of 501 small businesses found that 85% aren’t taking precautions, because they think they’re too small to be a target. If you, reading this blog post and think that you’re too small to be a target, please keep this in mind. Large numbers of hackers are constantly running automated scans of the Internet, like Google’s evil twin,
looking for vulnerable sites and flawed applications. Some of them are specifically looking for smaller companies with poor security. Those sites make great places to use as relays when attacking other companies: the hacker will break into your system, and then use your system to launch an attack on someone else. Perhaps worse, “obscure” sites are occasionally used by hackers to serve illicit content, like malware or even child pornography. The best that a small company with little security can hope for is that hackers will use their server to send spam. Being small just makes you a different kind of target, and applying even a basic level of security is a good investment.
As more mobile, web-based, and Enterprise applications get built and hosted on third-party platforms it is important to understand the potential hazards that application flaws might present to your network safety. It’s not just about the Quality of Service delivery of these applications — they can also be an easy way for attackers to penetrate your system. While following the steps above will not guarantee that you will avoid an attack, it will make you a more difficult target, and convince attackers to find someone easier.
Interested in learning more? Check out our post: “Next-Generation Firewalls and Classifying Network Applications” and “The New Face of Denial-of-Service Attacks“.