Interested To Learn More About
Your Website Security?
Get Your FREE Website Security Needs Assessment.
Top 10 Website Security Vulnerabilities
Security is not a list of things you do. Security is an active way of thinking, a way of looking at things, a way of dealing with the world that says “I don’t know how they’ll do it, but I know they’re going to destroy us in any way they can.” and then, rather than dissolving into an existential funk, being proactive to prevent the problem.
But, you can’t buck statistics. Nobody is going to read an article entitled “Coding for Security.”
Everyone wants an article with a number in it: “The 8 Most Common PHP Security Attacks and How to Avoid Them”, “10 Things Not to Say to a Super Model”,
and “15 Reasons to Avoid Radiation Poisoning.” So, here goes, the “Top 10 Website Security Vulnerabilities.”
Number one on the hit list is the SQL injection attack. In this case, someone enters an SQL fragment (the classic example is a drop database statement, although there are many possibilities that don’t include deletions which could be just as destructive) as a value in your URL or web form. Never mind now how he knows what your table names are; that’s another problem entirely. You are dealing with an insidious and resourceful enemy.
So, what can you do to avoid this? First and foremost you need to be suspicious of any input you accept from a user. Believe everyone is nice? Just look at your spouse’s family… they’re weird and freaky, some dangerously so.
The way to prevent this sort of thing is to use PDO Prepared Statements. We can’t go through a full discussion of PDO now. Suffice to say prepared statements separate the data from the instructions. In doing so, it prevents data from being treated as anything other than data.
XSS (Cross Site Scripting)
Curse the black hearts who thrive on this type of deception. Parents, talk to your children today lest they become evil XSS’ers!
Source Code Revelation
This one has to do with people being able to see the names and content of files they shouldn’t in the event of a breakdown in Apache’s configuration. Yeah, I dig it, this is unlikely to happen, but it could and it’s fairly easy to protect yourselves, so why not?
We all know that PHP is server side you can’t just do a view source to see a script’s code. But if something happens to Apache and all of a sudden your scripts are served as plain text, people see source code they were never meant to see. Some of that code might list accessible configuration files or have sensitive information like database credentials.
The solution centers around how you set up the directory structure for your application.
That is, it isn’t so much a problem that bad people can see some code, it’s what code they can see if sensitive files are kept in a public directory.
Keep important files out of the publicly-accessible directory to avoid the consequences of this blunder.
Remote File Inclusion
Hang on while I try to explain this: remote file inclusion is when remote files get included in your application. Pretty deep, eh? But why is this a problem? Because the remote file is untrusted. It could have been maliciously modified to contain code you don’t want running in your application.
Suppose you have a situation where your site at www.yourwebsite.com includes the library www.otherwebsite.com/script.php. One night, www.otherwebsite.com is compromised and the contents of the file are replaced with evil code that will trash your application. Then someone visits your site, you pull in the updated code, and Bam! So how do you stop it?
Fortunately, fixing this is relatively simple. All you have to do is go to yourphp.iniand check the settings on these flags.
- allow_url_fopen – indicates whether external files can be included.
The default is to set this to ‘on’ but you want to turn this off.
- allow_url_include – indicates whether the include(),require(),include_once(), and require_once() functions can reference remote files.
The default sets this off, and setting allow_url_fopen off forces this off too.
Session hijacking is when a hacker steals and use someone else’s session ID, which is something like a key to a safe deposit box. When a session is set up between a client and a web server, PHP will store the session ID in a cookie on the client side probably called PHPSESSID. Sending the ID with the page request gives you access to the session info persisted on the server (which populates the super global$_SESSION array).
If someone steals a session key, is that bad? And the answer is: If you aren’t doing anything important in that session then the answer is no. But if you are using that session to authenticate a user, then it would allow some vile person to sign on and get into things they should not be able to access. This is particularly bad if the user is important and has a lot of authority.
So how do people steal these session IDs and what can decent folk do about it?
Session IDs are commonly stolen via an XSS attack (which you read about above) so preventing those is a good thing that yields double benefits. It’s also important to change the session ID as often as practical to the environment.
This reduces your theft window. From within PHP you can run the session_regenerate_id() function to change the session ID and notify the client.
Session IDs can also be vulnerable server-side if you’re using shared hosting services which store session information in globally accessible directories, like /tmp.
You can block the problem simply by storing your session ID in a spot that only your scripts can access, either on disk or in a database.
Cross Site Request Forgery
Cross Site Request Forgery (CSRF), involves tricking a rather unwitting user into issuing a request that is, shall we say, not in his best interest.
Cross-site Request Forgery (CSRF) is a type of confused deputy attack which leverages the authentication and authorization of the victim when a forged request is being sent to the web server. Therefore, a CSRF vulnerability affecting highly privileged users, such as administrators, could result in a full application compromise.
During a Cross-site Request Forgery (CSRF) attack, the victim’s browser is tricked into sending HTTP requests to the web application as intended by the attacker, normally, such a request would involve submitting forms present on the web application to alter some data.
Upon sending an HTTP request (legitimate or otherwise), the victim’s browser will include the Cookie header. Cookies are typically used to store a user’s session identifier in order to avoid the user from having to re-authenticate for each request, which would obviously be impractical.
If the victim’s authentication session is stored in a Cookie which is still valid (a browser window/tab does not necessarily need to be open), and if the application is vulnerable to Cross-site Request Forgery (CSRF), then the attacker can leverage CSRF to launch any desired requests against the website, without the website being able to distinguish whether the requests are legitimate or not.
With a system vulnerable to directory traversal, an attacker can make use of this vulnerability to step out of the root directory and access other parts of the file system. This might give the attacker the ability to view restricted files, which could provide the attacker with more information required to further compromise the system.
Depending on how the website access is set up, the attacker will execute commands by impersonating himself as the user which is associated with “the website”. Therefore it all depends on what the website user has been given access to in the system.
This attack, like so many of the others, the bad guys look for a site where the level of security is not all that it should be,
it causes files to be accessed that the owner did not plan to make publicly accessible. It’s also known as the ../ (dot, dot, slash) attack, the climbing attack, and the backtracking attack.
There are a few ways to protect against this attack. The first is to wish really, really hard that it won’t happen to you.
Sometimes wishing on fairies and unicorns will help. Most times it doesn’t. The second is to define what pages can be returned for a given request using whitelisting. Another option is to convert file paths to absolute paths and make sure they’re referencing files in allowed directories.
These are the top 10 issues that, if you aren’t careful to avoid, can allow your website to be breached. Yep, 10. Count them… 1, 2, 3… What? You only counted 8? Okay, maybe 7.
Well then that shows you just how easily you can be fooled, and we're not even one of the bad guys!
Contact us below if you have any questions or security concerns with your own website.
Contact Us Here