After years in the industry and the webmaster circle, I know a bit about security. Many people get a security test report and are clueless about what those acronyms mean or how to fix them. Today, for those with no security background, I’ll roughly explain how these three types of attacks form; once you know the principles, you can defend. Since everyone uses different languages and frameworks, this intro focuses on how the attacks form and how to defend — so there’s little concrete code; you’ll implement it per your own situation.

What Is a CSRF Attack

First the term: CSRF (Cross-site request forgery). Still unclear? Don’t worry — here’s a real story. In 2009, a hacker used CSRF via Gmail to successfully hijack Hollywood star Vanessa Hudgens’s mailbox. The attack was simple: he sent her an email whose content was just an image, but a special one: <img src="https://mail.google.com/mail?ui=2&fw=true&fwe=my@email.com">. When the user opened the email and loaded the image, they actually visited that link — and that link’s function is Gmail’s email-forwarding setting, so all of the target mailbox’s mail was forwarded to the hacker’s specified address. There are many such examples: as long as you craft the right GET link and get the browser to send the GET request, it works, because the user is already logged in and carries the right cookie, so visiting the link directly triggers the function.

Once you know the principle, how do you defeat it? Add a Token field to the form. The hacker can’t guess a constantly changing token. Even if you add a UUID token saved in the server session, the hacker can’t guess this random token, so they can’t construct a working link.

What Is an XSS Attack

The term is actually CSS (Cross Site Scripting), but it clashes with Cascading Style Sheets, so it’s called XSS. XSS is similar to CSRF above: the principle is to inject a piece of JavaScript into a web page, which then runs when other users visit, achieving account control. A classic case: on 2011-06-28 Sina Weibo was hit by XSS, and huge numbers of users auto-forwarded posts, DMed, and auto-followed accounts — lots of users were mysteriously controlled. Because JS can click buttons and send requests on the user’s behalf, the harm is great.

Reflected XSS Attack: A common case is the search module. For example: https://www.neilren.com/Search?wd=attack. Normally the wd parameter carries the search term, which is then displayed on the page. You can use this entry to pass in different data, e.g. I change it to: https://www.neilren.com/Search?wd=

, and a JS snippet gets injected into the page. Likewise you can inject a cross-site JS file from another domain without the user noticing, enabling user control and cookie theft. But such a link only works if the user clicks it — not all users are hit.

Stored XSS Attack: Reflected XSS only hits users who click the link, but stored XSS can hit all users. A classic case is the user signature field, which lets users enter custom content stored in the database; when others view it, it’s loaded from the database. If a malicious user injects a JS reference in their signature, everyone who views them is controlled by the JS. Stored XSS can endanger the entire site’s users — very dangerous.

Once you know the principle, how do you defeat it? Many methods — e.g., keyword checking: when script, src, etc. appear, replace/destroy them; or encode the returned content, converting angle brackets to Unicode. See the screenshot below:

What Is a SQL Injection Attack

SQL injection is an old vulnerability, less common now; anyone with a little experience can avoid it. First a classic case: login code is often written like this

String sql = "select * from user where username = '" + userName "'' and passwd = '" +userPassword + "'";

Normally this concatenates to: select * from user where username = ‘admin’ and passwd = ‘mima’. But the hacker also knows SQL. They enter the username as admin' or 1=1 -- and the password as empty, producing:

select * from user where username = 'admin' or 1=1 -- ' and passwd = ''

See it? 1=1 is always true, and the trailing — comments out the rest of the SQL, so the admin user is successfully logged in. The principle is that simple.

Once you know the principle, how do you defeat injection? The most common is keyword checking at the business-logic layer: if SQL keywords like *, or, select, delete appear, replace them. The most effective of all is to use SQL parameters for queries, avoiding string concatenation of SQL.