Web development can be a tough job. A company’s web apps are often the most visible presence that they have on the Internet, and it’s the developer’s job to ensure that they work and work well. User experience research has demonstrated that seconds matter on a website – if you load too slowly or have a non-intuitive user interface, that can cost you major sales. The bottom line is that a lot of work needs to go into balancing functionality, efficiency, and design.
And, oh yeah, that web app also needs to be secure. Many, many webpages are designed to let anyone log in and interact with it, and often have a connection to a database that stores at least some type of sensitive information. Under the EU’s General Data Privacy Regulation (GDPR), the definition of “sensitive” user data has become pretty broad (even an email address counts) and the penalties are fairly stiff (4% of global turnover or 20 million euros, whichever is greater).
When dealing with web application security, one of the biggest threats that developers face is user input. You put a form field in a webpage and tell them that it’s for a phone number. 99% of people will only try to enter a phone number, but it’s that 1% that you have to watch out for. Mistakes in developing user interfaces can lead to compromises and are why we need web application firewalls (WAF).
Unexpected Input
Entering deliberately malicious input into an application is called an injection attack, and it’s one of the biggest threats that application developers face (consistently included on the OWASP Top Ten list of web application vulnerabilities). Today, over half of the attacks against web applications are injection attacks. More specifically, they are SQL injection attacks, meaning that the attackers are trying to access and steal data from your database.
SQL injection attacks (and injection attacks in general) exploit poor user input validation and how developers use this user input. SQL is a language for creating queries to a database, and it uses a single quote (‘) as a delimiter for user-provided input. For example, a valid SQL statement that takes user input may look like:
SELECT * FROM users WHERE name=’ ”+username+” ’
The purpose of this statement is to find all records in the user’s database where the username matches the value provided by the user and stored in username. The application developer expects an input like bob, which would produce the following statement:
SELECT * FROM users WHERE name=’bob’
This statement would produce the desired behavior of finding the record for user bob in the database, which allows the web application to load bob’s account. However, not all users are well-behaved.
One way to break this statement is to provide a username ‘ OR ‘1’=’1. The SQL statement that this would create is the following: SELECT * FROM users WHERE ‘’ OR ‘1’=’1’. Since 1 always equals 1, this statement will resolve to true for every record in the database, allowing the attacker to access the user data of everyone on the website.
This is only one example of an SQL injection attack on a web application. Alternatives include bypassing logins by providing a username and then using this attack on a password field so that the attacker can access a specific account. Without the appropriate protections in place, these sorts of attacks can lead to reportable (and fineable) breaches. Also, Read 7 Types of Network Attacks to Watch Out For in 2020.
Anti-Injection Defenses
The simple answer to protecting web applications from injection attack is writing secure code. The primary assumption made when performing this type of attack is that the user is capable of providing input that includes the single quote (‘) character that is passed unchecked into the SQL statement.
Blocking any user input that includes a single quote character would protect against this type of attack. If the open quote coming before user input is not closed, anything that is located between the opening and closing quote is considered the field to search for in the database. You may end up looking for a user with a very weird name, but your database will remain secure. The issue with this approach is that it assumes that the developer identifies and properly protects every possible means by which the attacker can enter user input. People make mistakes sometimes, and it’s wise to have some automated defenses in place to help prevent this type of attack.
Preventing injection attacks (and many other types of attacks) is what web application firewalls (WAFs) are designed to do. Protecting against the OWASP Top Ten is a bare minimum for a WAF, and some provide additional, advanced functionality like anomaly detection designed to detect new types of attacks against your website. Your web presence is the public face of your business, and it’s always worth the investment to protect it.
Protecting Your Web Apps
Web applications are an extremely useful and valuable way for organizations to interact with their customers, but they can be very dangerous as well. Many of these applications provide a direct connection between the user and a database that contains information protected under data privacy regulations. Avoiding costly penalties and loss of face requires protecting this data properly.
Secure programming practices are a good start when developing web applications, but the fact that we still have an OWASP Top Ten list of web application vulnerabilities demonstrates that they’re not always followed. Deploying a strong web application firewall should be a component of every organization’s cybersecurity strategy to help protect the public face of their business.
