Some of that code might list accessible configuration files or have sensitive information like database credentials. 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. We all know that PHP is server side – you can’t just do a view source to see a script’s code. Yeah, I dig it, this is unlikely to happen, but it could and it’s fairly easy to protect yourselves, so why not? 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. Input Validation Using Filter Functions by Toby Osbourn.Cross Scripting Attacks by George Fekette.
Please don’t make me go into detail my heart weeps at what these brigands are capable of.įor more information and how to protect yourself, I suggest reading these fine articles on PHPMaster: The attacker may post JavaScript code in his message that does unspeakable things to your site. This attack is possible when you display input that was sent to you, such as you would do with a forum posting for example. The essence of any XSS attack is the injection of code (usually JavaScript code but it can be any client-side code) into the output of your PHP script. Parents, talk to you children today lest they become evil XSS’ers!
XSS (Cross Site Scripting)Ĭurse the black hearts who thrive on this type of deception. For more info, you might want to check out the article Migrate from the MySQL Extension to PDO by Timothy Boronczyk. In doing so, it prevents data from being treated as anything other than data. Suffice to say prepared statements separate the data from the instructions.
I don’t want to go through a full discussion of PDO now. The way to prevent this sort of thing is to use PDO Prepared Statements.
Believe everyone is nice? Just look at your spouse’s family… they’re weird and freaky, some dangerously so. So, what can you do to avoid this? First and foremost you need to be suspicious of any input you accept from a user. You are dealing with an insidious and resourceful foe. Never mind now how he knows what your table names are that’s another problem entirely. 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. Number one on the hit list is the SQL injection attack. 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”, “23 Things Not to Say to a Super Model”, and “15 Reasons to Avoid Radiation Poisoning.” So, here goes, the “Top 10 PHP Security Vulnerabilities.” SQL Injection Security is a 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 try to screw me” and then, rather than dissolving into an existential funk, being proactive to prevent the problem.īut, you can’t buck statistics.