Application Security and OWASP Threats

What it is

Application security is the set of practices that keep an application and its data safe from misuse.

This page covers three areas: protecting secrets, encrypting data in storage and in transit, and handling data carefully. It then looks at the common web attacks that the OWASP project lists, including XSS, SQL injection and CSRF.

OWASP is the Open Worldwide Application Security Project, and its Top 10 list ranks the most serious web application risks.

How it works

Security comes from layers: protect the secrets, protect the data, and validate every input.

Secret protection

Secrets are passwords, API keys, tokens and the private keys of certificates. Anyone who holds one can act as the owner.

• Never write secrets in source code or commit them to Git.
• Load them at run time from environment variables or a secrets manager.
• Give each secret the least access that it needs.
• Rotate secrets on a schedule, and replace one at once if it leaks.
• Keep them out of logs and error messages.

import os

API_KEY = os.environ["API_KEY"]

A secret that was committed to Git stays in the history even after the file is changed, so treat it as leaked and replace it.

Encryption in storage

Encryption at rest protects data on disks, in databases and in backups. If the storage is stolen, the data stays unreadable without the key.

Passwords are different. Do not encrypt them for later use. Store a salted hash made with a slow algorithm, so that the original password cannot be recovered.

Encryption in transport

Encryption in transit protects data as it crosses the network. Use TLS, which is the basis of HTTPS, for web traffic and APIs. Use SSH instead of Telnet for device access.

Check certificates and do not turn off verification in production. Without TLS, an attacker on the path can read or change the traffic.

Data handling

• Collect only the data you need.
• Validate input on the server, whatever the client checks.
• Limit who can read each type of data.
• Do not put personal data in logs.
• Delete data when it is no longer needed, and follow the rules that apply to your data.

OWASP threats

SQL injection

If code builds a query by joining text, an attacker can add their own SQL.

# unsafe
query = "SELECT * FROM users WHERE name = '" + name + "'"

# safe: the driver passes the value separately
cursor.execute("SELECT * FROM users WHERE name = ?", (name,))

An input such as ' OR '1'='1 would change the meaning of the unsafe query. In the safe form, the value is treated as data and never as SQL.

Cross site scripting

An application that shows user input without escaping it can deliver a script to other visitors. That script can steal session cookies or change the page. The fix is to escape or encode output for the place where it appears, and to validate input.

Cross site request forgery

A page on another site makes the victim's browser send a request to your application, and the browser attaches the user's login cookie. The application cannot tell it from a real request. A secret token in each form, which an attacker cannot guess, stops it.

General defences

Keep software patched, give accounts only the rights they need, log security events, and test for these flaws before release.