The field of web application security involves all topics related to keeping websites secure, including understanding threats and attacks against websites as well as designing and building secure websites.
Though some threats are not specific to web applications and can impact other types software, other threats are unique to web applications due to the nature of browsers and the web.
The majority of attacks on web applications involve an attacker making a specially crafted request to a website.
Although the exact format of a malicious request depends on the particular application and vulnerability, there are many elements of malicious requests that are predictable or unlikely to be seen in normal (non-malicious) requests. Additionally, applications such as WordPress are often exploited through vulnerabilities in specific, exposed areas of the application.
One common web application vulnerability is when a vulnerable application's code allows attackers to provide their own database commands that the application will then execute on its database. This is known as a SQL injection attack.
SQL (Structured Query Language) is the language programmers use to interact with a database. SQL commands ask the database to read data from the database as well as to insert, update, and delete data.
A simple SQL statement to update a password is shown below. This example would be insecure for additional reasons, but we're focusing only on SQL injection for this example.
UPDATE users SET password = "my_new_password" WHERE email = "email@example.com"
In a poorly written application, a programmer may use an email address submitted through a website form and use that email address directly in a SQL query like the one above.
What happens if instead of the user submitting firstname.lastname@example.org they instead sent the following strange looking line of text as the email address?
" OR email = "email@example.com
When that text gets used as the email address the SQL statement, the resulting SQL statement would look like this:
UPDATE users SET password = "my_new_password" WHERE email = "" OR email = "firstname.lastname@example.org"
That unusual but valid SQL command would have the impact of changing a different user's email address than the email address the web developer intended.
The best way to keep applications secure is obviously to not have vulnerabilities in the first place. Of course, this is easier said than done.
As software grows in complexity, it becomes harder to keep the software free of bugs, including security bugs. Preventing unnecessary complexity is a first step in building secure software.
Next, there are many practices developers can follow that eliminate entire classes of vulnerabilities. This includes using software frameworks that prevent developers from writing dangerous code as well as practices such as having other developers review proposed code changes to find bugs before they get added to software.
However, though decreasing the number of bugs is vitally important, some security bugs can still end up in software.
For web applications, the use of a Web Application Firewall (WAF) is a common approach to preventing security vulnerabilities from being exploited. A WAF looks at the content of requests before they are processed by an application. If the request appears malicious, the request is blocked. In the SQL injection example above, a WAF can identify SQL commands in the content of the request and conclude that the request is an attack.
Learn about the most common types of web application vulnerabilities.