Web Security 101 - Part 2: User Input

Never trust anything a user puts into your app.

1. Listing


2. Input Validation


3. Encoding


4. Sanitization


5. XSS


6. SQL Injection


7. Command Injection


8. Client-Side Authorization

Listing

Cybersecurity has multiple types of listing.

• Whitelisting is making a list of values that are allowed. For example, a CORS policy that only allows requests from a list of certain sites.


• Blacklisting is making a list of values that aren't allowed. For example, blocking a number on your phone.


• Allowlisting is making a list of trusted files, applications, and processes that are allowed to run.


• Greylisting is making a list of values that are temporarily allowed. Called grey because it's in between black and white, this is typically for access control. For example, a user only needs write permissions for the database for one task, and you want to revoke access afterwards.

All of these are tools in your toolbelt, to be used with other tactics. Whitelisting is typically more useful than blacklisting. If attackers come up with a new thing, it'll be allowed by your blacklist, but it still won't be allowed by your whitelist.

Input Validation

Input validation isn't just for thwarting attacks. Making sure your data is properly formatted will also prevent errors.

Syntactic validation checks for the correct syntax. When you check that a user's input in an email field is in an email format, that's syntactic validation.

Semantic validation checks the values of the user input. For example, that they entered a date that already happened in a date field.

.

By only allowing through values we know to be in a good format, we are whitelisting. If we were to only blacklist certain values we know to be malicious, we'd probably miss malicious values and allow badly formed data into our app.

The HTML element <input> has 21 possible values for the type attribute. Many of them automatically validate the user input, like email.

<label for="email">e-mail address</label>

<input type="email" id="email" name="email">

Just like that, your input will validate that the user entered text in an email format. Anything else will be invalid. In JavaScript, you have access to the . Like making a type in a .

Encoding

Encoding converts data into another format. For security and utility, your encoding should be context-sensitive. For example, React will not take children elements in an object. You would have to encode them in an array.

Encryption is beyond the scope of this blog, but it is a type of encoding.

Another type of encoding is serialization or turning data into a string so it can be transmitted easily. In JavaScript, JSON.stringify serializes JSON.

JSON.parse, on the other hand, takes a JSON string and encodes it as a JavaScript object. JSON.parse will not execute code, but if you encode a script inside a valid string of JSON, it might execute wherever you pass it.

To prevent that, we sanitize data.

Sanitization

Where serialization and parsing ensure your code is valid, sanitization ensures your code is safe and desired. It is also context-sensitive. HTML in a string on the back-end is fine. HTML in a web page would execute and needs to be run through a sanitizer that anticipates it being in a web page. Tags and attributes that can execute code, such as <script> and onClick, will be removed. Illegal characters will be removed.

Characters will also be escaped. Escaping takes one character a parser might recognize as code to execute and turns it into another. Sometimes, this is done with "escape characters". For example, /s might mean something, but once we add the escape character /, it becomes //s which means nothing.

on them.

Markdown

Like HTML, code in markdown can be executed. You can use a .

URL

Yes, you can send malicious code in a URL too. In JavaScript, will escape characters. You'll have to manually check and filter the rest of it, but the .

XSS

If you take input from a user and then display it on a page, that is an attack vector for is when an attacker includes

The best way to stop this kind of attack is to never use user input in a SQL command. If you absolutely have to, you can use parameterization and stored procedures. Check out is when a malicious Operating System (OS) command is included in user input. Instead of being executed in your application, this code is executed by system commands on your computer.

Again, the best way to stop this kind of attack is to never use user input in an OS command in your server. If you absolutely have to for some reason, validate, encode, and sanitize.

Client-Side Authorization

Since I touched on access control in listing and it kind of applies here, I wanted to briefly mention something I see a lot - client-side authorization.

As I harped on in Secrets, the user has access to everything in the browser. If you conditionally load components using state variables based on the user's role, it's pretty dang easy for a user to figure it out and change the value in DevTools. Same goes for using the router, e.g. just changing the URL. Once you start seeing patterns in URL parameters, it's trivial to start guessing at what other values might get you.

If you don't validate that the user is who they say they are on the back-end every time they try to access information, anyone can impersonate another user or role. These checks are important if there's user input and doubly so if that user input is put into the database.

Conclusion

Web Developers build a lot of forms, so learning how to protect yourself from malicious user input is key. Never ever ever trust any user input.