The first thing is, unless you really know what you're doing, use some sort of fully managed framework and do not under any circumstances reinvent any of the wheels they give you. For instance, if they have an authentication library, use it and do not roll your own.
I'll keep details of exploitation methods to the absolute minimum needed for you to understand and mitigate an attack and will leave out intricate details to help keep this thread in line with FP rules.
Beyond that, a few things I would say are:
You either want a strongly typed language or one which allows you to use type-hints to help reduce the chances of someone passing a string where you expect a string or an array where you expect a string.
An adversary could take advantage of your oversights or your lack of knowledge on how a system works to squeak in vulnerabilities in that way and often, ones of the methods is passing a strange type in a strange place.
If you're comparing two large strings, possibly session strings or handling cryptography in general, you will want a constant time compare, otherwise an adversary will take advantage of the time the comparison takes to execute.
Why? When you do a compare, you really need to think of it as an iteration over an array with each byte being checked one by one. If it discovers that the two do not match, then it breaks out of that loop early, however, an adversary could time that and use that knowledge to deduce the characters in a session string or some other bit of information byte by byte.
Attacks of this nature have been in the wild for over a decade, but they've become particularly prevalent for targeting weak implementations of cryptographic algorithms to steal people's money.
The main one you're probably aware of is the SQL Injection, but really, everyone here should know what it is. If you do not know what XSS and SQL Injections are and how they work, then you are not fit to do web development, read up on them first or you might wind up getting screwed over by bots or worse.
I'll go over it anyway.
With SQL, you execute a query of the nature of `SELECT * FROM users WHERE uid = 1;`
However, when you introduce user input, a user might be able to mutate that string with strange characters or sequences which steps past WAFs and whatever query sanitisation function you've used and can turn a single query into query.
Don't try to be smart, being smart has gotten countless sites and large corporations in trouble with little gain. If you insert user input into the query string, it is vulnerable.
The only real method to counter SQL Injections is with a prepared statement which separates the user input from the query string and sends the two separately, so one cannot influence the other.
It is a modern practice which every modern software uses, either directly or via a framework's abstraction. If you concatenate the query string with the user input, then you are in serious danger, even if you think you've sanitised the bad input away, as humans make mistake, particularly in highly complex systems and sanitisation methods aren't as good as you'd think.
SQL Injections are really a solved problem though, consigned to legacy systems like Wordpress, vB3, the free major forum software, etc. which have mountains of code to modernise and countless plugins to break.
Another thing I'll say is never trust the user or anything coming from their machine. For anything. Verify state on your side and avoid leaving anything to the user, even if you think your implementation running on their machine is "encrypted".
To deal with XSS, you most likely want a template system which automatically encodes data passed to it in a harmless form, unless you specify otherwise to that. Failing that, you want to encode all data from the user as HTML entities, and you might even want to set a content security policy header to kill any scripts on the page which were not created by you or your associates.
One big offender is XML. And the one thing I'll say is. Don't use XML. Use JSON.
In fact, don't touch anything with XML in it, if at all possible.
Your adversaries will know all sorts of odd features and behaviours of XML which you don't to DoS or compromise your systems. Using XML is putting you and your users at risk.
Keep important files and folders outside of /www/ and similar folders, as an adversary could trick the webserver into revealing sensitive documents or attachments. In fact, if possible, avoid building software which exist within such folders and are capable of running outside them.
Never allow an admin to use a database without a password set.
Avoid using or officially supporting an end of life version of Linux, MySQL, Go, PHP, Apache, etc.
All that does is encourage people to stick with old systems. And can result in an adversary elevating themselves to root aka administrator level privileges on your machine.
Don't treat PHP like a template language. That is asking for trouble.
Test to make sure your sessions, authentication systems, permissions, etc. actually work and do it regularly. Things do stop working accidentally.
Write unit tests and functional tests to help catch regressions and bugs.
Test to see if you bypass your layers of validation and authentication, even if you "think" they work. Think how and what an adversary might do against you and beat them to cracking your system open first to find ways to harden it.
Don't trust PHP's serialize() function with user input, in fact don't use it at all, if possible.
Don't trust PHP's native sessions feature.
Strip null bytes from user provided inputs, it's a common way to attack vulnerabilities in PHP itself or other systems written in C.
Guard against CSRF.
Sensitive information or that which can be used to help an adversary figure out the weaknesses in your system can be leaked via error messages. Make sure only administrators can see those, probably by logging them and hiding them for regular users.
Ask someone other than yourself to review your code for oversights and security vulnerabilities. People make mistakes and an extra pair of eyes always helps.
Be paranoid. Be vigilant. And always think about how someone might get through your defences in this wild, wild world. There is probably much I haven't mentioned, so make sure you read up on ways to further secure yourselves.
I'll keep details of exploitation methods to the absolute minimum needed for you to understand and mitigate an attack and will leave out intricate details to help keep this thread in line with FP rules.
Beyond that, a few things I would say are:
You either want a strongly typed language or one which allows you to use type-hints to help reduce the chances of someone passing a string where you expect a string or an array where you expect a string.
An adversary could take advantage of your oversights or your lack of knowledge on how a system works to squeak in vulnerabilities in that way and often, ones of the methods is passing a strange type in a strange place.
If you're comparing two large strings, possibly session strings or handling cryptography in general, you will want a constant time compare, otherwise an adversary will take advantage of the time the comparison takes to execute.
Why? When you do a compare, you really need to think of it as an iteration over an array with each byte being checked one by one. If it discovers that the two do not match, then it breaks out of that loop early, however, an adversary could time that and use that knowledge to deduce the characters in a session string or some other bit of information byte by byte.
Attacks of this nature have been in the wild for over a decade, but they've become particularly prevalent for targeting weak implementations of cryptographic algorithms to steal people's money.
The main one you're probably aware of is the SQL Injection, but really, everyone here should know what it is. If you do not know what XSS and SQL Injections are and how they work, then you are not fit to do web development, read up on them first or you might wind up getting screwed over by bots or worse.
I'll go over it anyway.
With SQL, you execute a query of the nature of `SELECT * FROM users WHERE uid = 1;`
However, when you introduce user input, a user might be able to mutate that string with strange characters or sequences which steps past WAFs and whatever query sanitisation function you've used and can turn a single query into query.
Don't try to be smart, being smart has gotten countless sites and large corporations in trouble with little gain. If you insert user input into the query string, it is vulnerable.
The only real method to counter SQL Injections is with a prepared statement which separates the user input from the query string and sends the two separately, so one cannot influence the other.
It is a modern practice which every modern software uses, either directly or via a framework's abstraction. If you concatenate the query string with the user input, then you are in serious danger, even if you think you've sanitised the bad input away, as humans make mistake, particularly in highly complex systems and sanitisation methods aren't as good as you'd think.
SQL Injections are really a solved problem though, consigned to legacy systems like Wordpress, vB3, the free major forum software, etc. which have mountains of code to modernise and countless plugins to break.
Another thing I'll say is never trust the user or anything coming from their machine. For anything. Verify state on your side and avoid leaving anything to the user, even if you think your implementation running on their machine is "encrypted".
To deal with XSS, you most likely want a template system which automatically encodes data passed to it in a harmless form, unless you specify otherwise to that. Failing that, you want to encode all data from the user as HTML entities, and you might even want to set a content security policy header to kill any scripts on the page which were not created by you or your associates.
One big offender is XML. And the one thing I'll say is. Don't use XML. Use JSON.
In fact, don't touch anything with XML in it, if at all possible.
Your adversaries will know all sorts of odd features and behaviours of XML which you don't to DoS or compromise your systems. Using XML is putting you and your users at risk.
Keep important files and folders outside of /www/ and similar folders, as an adversary could trick the webserver into revealing sensitive documents or attachments. In fact, if possible, avoid building software which exist within such folders and are capable of running outside them.
Never allow an admin to use a database without a password set.
Avoid using or officially supporting an end of life version of Linux, MySQL, Go, PHP, Apache, etc.
All that does is encourage people to stick with old systems. And can result in an adversary elevating themselves to root aka administrator level privileges on your machine.
Don't treat PHP like a template language. That is asking for trouble.
Test to make sure your sessions, authentication systems, permissions, etc. actually work and do it regularly. Things do stop working accidentally.
Write unit tests and functional tests to help catch regressions and bugs.
Test to see if you bypass your layers of validation and authentication, even if you "think" they work. Think how and what an adversary might do against you and beat them to cracking your system open first to find ways to harden it.
Don't trust PHP's serialize() function with user input, in fact don't use it at all, if possible.
Don't trust PHP's native sessions feature.
Strip null bytes from user provided inputs, it's a common way to attack vulnerabilities in PHP itself or other systems written in C.
Guard against CSRF.
Sensitive information or that which can be used to help an adversary figure out the weaknesses in your system can be leaked via error messages. Make sure only administrators can see those, probably by logging them and hiding them for regular users.
Ask someone other than yourself to review your code for oversights and security vulnerabilities. People make mistakes and an extra pair of eyes always helps.
Be paranoid. Be vigilant. And always think about how someone might get through your defences in this wild, wild world. There is probably much I haven't mentioned, so make sure you read up on ways to further secure yourselves.
Last edited:
