As mentioned in a previous article Front-end, Back-end and database-side – The Structure of an App, server architectures can get pretty complicated. The more sturdy and secure you want your application to be the more complicated it will get. I’ve seen architectures with so many checks and balances that multiple people with multiple types of privileges are necessary to get into the setting of a system and bypass the firewall. Trust me, you can make these things pretty secure. However, many start-ups and small businesses will not need this type of security. Let’s discuss the general security concepts that we will want to consider in these cases.
Let’s start with the client-side, the definition of which has been discussed in Front-end, Back-end and database-side – The Structure of an App. The major security risk that we face on the client-side involves user input. Here, we have to make sure we watch out for malicious code injections from users and bots trying to hack our site. Any developer that has been around for a few years, probably even less, will be aware of these type of security risks and mitigate the risk in their code. However, you will need to make sure that this indeed has been done.
The problem of injections arises when user input text is combined, or concatenated, with internal code in a way to mislead the language interpreter to take the input text as instruction code. There are many examples of this, one of which is escaping code with a quote or a double quote. Hackers know that text (as opposed to code) in JavaScript begins and ends with a quote or a double quote. Below I will try to demonstrate the example without using any code. Instead, I will indicate the difference between text interpreted as code (a set of instructions to the language interpreter) and text meant to be treated as a literal entity and not as code instructions. The text that will be interpreted as code will be in blue and the text that will be interpreted as simple text will be in red
//quote example
This text as code instructions 'text here meant to be taken as text due to single quotes around it' some other instructions here
//double quote example
This text as code instructions "text here meant to be taken as text due to double quotes around it" some other instructions here
In the above example the ‘input user text here’ is what a user of the app types in as an entry into a textbox. You can see that, if instead they type in ‘input user ‘text here’, the language interpreter can treat the extra ‘ as a marker to end the textual literal and treat the rest of the user input string as code instructions. In this was, a hacker entering input into your app can gain control of your application and even your data.
//quote example with hacker ' injected to end the text string - causing the last part ( text') to be interpreted as code/instructions rather than plain text
code here 'input user' text' code here
//quote example with hacker " injected to end the text string - causing the last part ( text") to be interpreted as code/instructions
code here "input user" text" code here
To prevent this type of hack, your developer can either search for troublesome characters in the input user code and “escape” them, or they can search for all improper characters and if any are found throw a message to the user that the input is unacceptable and the user needs to re-enter the input without funky characters.
“Escaping” is a term used for troublesome characters that you mean to treat as simple text instead of code instructions. In JavaScript, for example, we replace ‘ or ” with \’ or \” in the input text which tells the JavaScript interpreter that the quote or double quote does not end the input text but is in fact still part of the input text. With the escape characters in place the JavaScript interpreter won’t end the text string in an unsafe place and treat the entire user input as simple text.
//examples of safe code
//quote is escaped with \ making the JavaScript interpreter understand to treat the double quote as text and not the end of the text
code here 'input user\' text' code here
//double quote is escaped with \ making the JavaScript interpreter understand to treat the double quote as text and not the end of the text
code here "input user\" text" code here
//here, single quote is the marker of where to end the text input so a double quote within single quotes is safe
code here 'input user" text' code here
//similar to the above example, a single quote is safe in between double quotes
code here "input user' text" code here
Another way to deal with potentially unsafe user input is to keep a list of all characters that you would not like the user inputting. When a user input comes in make sure that it does not contain any of these characters. If it does, throw a message to the user telling them that the input is not acceptable and they need to try and input it again without any unsafe characters.
This topic in particular can get very extensive, so feel free to ask questions. In general, this type of code injection is referred to as XSS – or Cross-site Scripting.
To continue the discussion of the security of our app architecture let’s proceed to Server-Side Security Concepts in the next article.
