Secure coding: input validation, SQL injection, XSS, buffer overflow, CSRF

Last week we talked about design decisions. This week we go down to individual lines of code. The question type that almost certainly appears on the exam: you are given a vulnerable piece of code and asked “what is the vulnerability, how do you fix it?” or “what query is executed for this input?”. All five vulnerabilities come from the same root: trusting data that comes from outside and mixing data with code.

Golden rules:

1. All input is hostile. Form fields, URLs, cookies, HTTP headers, file names, API responses.
2. Validate on the server. A JavaScript check is for the user; the attacker skips it.
3. Separate data from code. Parameters for SQL, encoding for HTML, an argument array for commands.
4. Know the limits. In C, the size of every buffer and the \0 byte must be in the calculation.
5. Every state-changing request needs proof. No transfer without a CSRF token.

The code snippets on this page are for understanding and fixing the vulnerability. Trying them without permission on a real system is a crime.

Input validation

There are two approaches:

An allowlist example: a username is only letters, digits, underscore and 3-16 characters.

const USERNAME = /^[A-Za-z0-9_]{3,16}$/;
for (const s of ["deniz_07", "ab", "ali veli", "x<script>", "AAAAAAAAAAAAAAAAA"]) {
  console.log(JSON.stringify(s), USERNAME.test(s));
}

"deniz_07" true
"ab" false
"ali veli" false
"x<script>" false
"AAAAAAAAAAAAAAAAA" false

The last input is 17 characters, one too many. The ^ and $ anchors are a must: without them the regex matches a part of the text and the rest is not checked.

PITFALL · validation is not the only defense. In a name field O'Brien is legitimate, and it contains a quote. That is why, besides validation, parameters for SQL and encoding for HTML are also needed. Validation answers the question “is the format right”, and encoding answers “is it safe in this context”.

SQL injection

The problem is building the query by string concatenation:

// VULNERABLE: the input is pasted into the SQL text
String sql = "SELECT * FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

The classic textbook example: name = ' OR '1'='1. The text becomes:

SELECT * FROM users WHERE name = '' OR '1'='1'

'1'='1' is true in every row, and the query returns the whole table. A simulation on a table with three users:

rows matched (concat)   3
rows matched (param)    0

The fix is a parameterized query:

// SAFE: the query structure is fixed, the input is only a value
PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

The database compiles the query first and never interprets the value that arrives in place of ? as SQL. With the same input it looks for a user whose name is exactly ' OR '1'='1, and 0 rows are returned.

Extra layers: give the database user only the privileges needed on only the tables needed (least privilege), don’t show SQL details in error messages, and if you use an ORM, avoid concatenating raw queries.

PITFALL · AND/OR precedence. In the query ... WHERE user = 'admin' AND pass = ' + input + ', if the input is x' OR 'a'='a, the text becomes user = 'admin' AND pass = 'x' OR 'a'='a'. AND binds first: (user='admin' AND pass='x') OR 'a'='a', and the result is true for every row. The fix is again a parameter.

Cross-site scripting (XSS)

In XSS the attacker runs their own script on another site’s page, in the browser of that site’s user. Stealing cookies, showing fake forms and acting on behalf of the user become possible.

Vulnerable and fixed code:

// VULNERABLE: the user's text is interpreted as HTML
comment.innerHTML = userText;

// SAFE: inserted as text, creates no tags
comment.textContent = userText;

If you use templates on the server side, encode the output for the HTML context:

const esc = (s) => s.replace(/&/g, "&amp;").replace(/</g, "&lt;")
  .replace(/>/g, "&gt;").replace(/"/g, "&quot;").replace(/'/g, "&#x27;");
console.log(esc('<b>"Hi"</b>'));
console.log(esc("<script>alert(1)</script>"));
console.log(esc("Tom & Jerry's"));

<b>"Hi"</b>
<script>alert(1)</script>
Tom & Jerry's

& is always replaced first; otherwise the & in the < produced later would be encoded again. Context matters: the rules are different for the HTML body, an HTML attribute, JavaScript text and a URL. Modern template engines (React JSX, Thymeleaf) encode by default.

The second layer is Content Security Policy: the header Content-Security-Policy: script-src 'self' tells the browser to run only script files that come from its own origin, and inline scripts are blocked. The third layer: giving the session cookie HttpOnly, so JavaScript can’t read the cookie.

Buffer overflow (C)

C arrays don’t know their size. strcpy copies until it sees the end of the source (\0), and doesn’t check whether the destination is full.

/* VULNERABLE */
void greet(const char *name) {
    char buf[10];
    strcpy(buf, name);          /* no length check */
    printf("Hello %s\n", buf);
}

If name = "HelloWorld!!" (12 characters), 13 bytes are written, overflowing the 10-byte buffer by 3 bytes. On the stack, beyond the buffer, there are other variables and the function’s return address; corrupting them means a crash or hijacking of the control flow.

/* SAFE */
void greet(const char *name) {
    char buf[10];
    if (strlen(name) >= sizeof buf) {   /* leave room for \0 */
        fprintf(stderr, "name too long\n");
        return;
    }
    snprintf(buf, sizeof buf, "%s", name);
    printf("Hello %s\n", buf);
}

Compiler and operating system layers (stack canary, ASLR, DEP/NX) make the attack harder but do not fix the bug. The lasting solution is bounds checking or a memory-safe language (Java, Rust, Go).

PITFALL · off-by-one. For char buf[16], the longest safe text is 15 characters. If you write if (len <= sizeof buf), 16 characters + \0 = 17 bytes are written. The right one is len < sizeof buf.

Cross-site request forgery (CSRF)

The user is logged in to the bank, and the session cookie is in the browser. On another site a hidden form automatically sends a POST to the bank. The browser adds the cookie by itself, and the server thinks the request came from the user. The difference from XSS: the attacker doesn’t run code on the bank’s page, they only make the user’s browser send a request.

<!-- VULNERABLE: the server looks only at the cookie -->
<form action="/transfer" method="POST">
  <input name="to"> <input name="amount">
</form>

<!-- SAFE: a session-bound, unpredictable token -->
<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="(sunucunun ürettiği rastgele değer)">
  <input name="to"> <input name="amount">
</form>

On every state-changing request the server compares the token with the value in the session and rejects the request if they don’t match. The attacker’s page can’t read this value (same-origin policy). Additional defenses: giving the cookie SameSite=Lax or Strict (the cookie is not sent on a cross-site POST), asking again for a password or MFA on critical operations, and never using GET requests to change state.

Common mistakes

String sql = "SELECT * FROM users WHERE name = '" + name + "'";
ResultSet rs = stmt.executeQuery(sql);

PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE name = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

char buf[8];
strcpy(buf, input);   /* no length check */