Useful read for those who blindly include from the GET string.
Useful read for those who blindly include from the GET string.
Are you a Help Vampire?
Jem is a self-proclaimed l33t PHP ninja, and she knows what she's talking about. :P
Keep an eye on her website, she's very helpful on the subject and has many posts concerning it.
1. Only use error_reporting(E_ALL) while developing, in the release use error_reporting(0)
2. Don't be afraid to ask questions and get help
3. Report ANY errors/warnings
4. Never trust $_SERVER as it can be modified
5. Never trust anybody
6. The PHP manual can be very useful; don't be afraid, it's your friend.
7. Have people test your projects
8. XSS/CSRF etc attacks
9. Sanitize any user input (Forms, Get, Post, etc..)
10. Be especially careful if you use HTML selects, checkboxes, or radio buttons in forms, they can be changed by the user
11. Time and patients can make the biggest difference
12. You should probably make sure you're comfortable with any language you write a script/program in.
13. Lean by example -- look at other people's script.
14. Try to "break" the script on test runs
15. Password encryption
16. Never store sensitive stuff in .inc.php files
17. Place all config files, .ht* files out of your root directory
18. Ask questions: What could I have done differently? Why does X do this? Why does Y do that.
Sorry if the wording of these tips is a bit odd. :P
Kinda posted this in a hurry!
Last edited by johnnnn; 08-09-2010 at 11:17 PM.
To add to this, don't forget that % and _ are both special characters in SQL. It is, however, much safer (harder to make mistakes) to limit input to the characters you want (e.g. [a-zA-Z0-9]) than to hope that you have a complete list of all SQL special characters.
IPTables can limit the number of connections an IP address can make in a given time limit and will simply drop packets until the IP address is below the limit again. You can also limit IP addresses by bandwidth in a given time limit. I'm sure other firewalls will have similar capabilities. Filtering such as this should be done as early as possible in the path through your system as that is where it has already had the least impact on the other users of your system.
I don't have a problem with calling your super user "root" but there is no harm in changing it. You should, however, definitely not allow this user to log in over the network. If the root user can log in over the network then an attacker brute forcing his way in already knows one username (and it's the most powerful user to boot)
Strangely enough, this post is almost not about PHP at all, but security involves the entire system so we shouldn't just focus on PHP anyway.
Thanks for the tips.
hey, this is nice post.
i have a simple way to prevent sql injection attact. usually, hacker test if sql vulnerable by adding a single or doble quote in input variable. like this:
?id=1' or ?id=1"
so, i remove any quote in all variable. i use str_replace().
i see why hacker do to attack sqlinjection vulnerability. like this:
so, i remove the +,-,%20,*.
i feel this is just little trick, but this so helpfull to prevent sql injection attact :-)
I am sorry my english is very bad. But I am very interest to discusse here :-)
Lovely tut....This type of sticky notes can help beginners like me......
Last edited by VIPStephan; 01-31-2013 at 07:59 PM. Reason: removed huge quote
When developing your own PHP scripts, be aware of security issues. Also view the OWASP Top 10 Security Vulnerabilities. Listed below are some things you can do which will make your web application more secure. For more information, visit the links above.
Always validate user input before using it to do anything in your script. Even form variables such as select boxes need to be validated to ensure that the value chosen is in the original list of values.
Always escape characters such as single or double quotes, backslashes (\), percent symbols, and other characters which could result in an unexpected use of your script.
Take extra precaution when executing commands with user input in them. It is possible for an attacker to inject a malicious command in this way.
When dealing with secure information (such as passwords), be sure to use a good password that will be hard (or better yet, impossible) to guess. Generic passwords such as 'admin', should never be used. The same goes for dictionary words. Secure passwords will be at least 8 characters long, contain at least one (1) numeric digit in them, and do not contain dictionary words. Never store passwords in plain text, always encrypt then with an irreversible encryption algorithm such as MD5.
Stay away from using default filenames, such as putting administrative functionality in the admin/ folder. Generic names such as this are easy targets for hackers to attempt to access.
When instantiating PHP on a page, always use the full <?php and ?> tags. Using shortcut tags such as <? to instantiate php could result in your script being displayed as plain text if the server configuration is changed.
Thanks for sharing this list!
i disagree with one point. I use md5() instead of hash.
If someone is using md5, always with some "strange" salt (a big unique word) what problem will have ????
These days, md5 is outdated and easily reverse engineered. See this: PHP: Password Hashing - Manual. Other, more secure PHP hashing functions exist. For example: PHP: hash - Manual. And this function allows you to see available hashing algorithms: PHP: hash_algos - Manual. So if a function like hash() exists that enables you to pick and choose a more secure hashing algorithm for your application, and it is easily consumed, then why wouldn't you use it? In my opinion, there is no such thing as too much security in web applications. The tradeoff between usability/cost of development and security is negligible when the cost of having your data compromised grows bigger every day! And with computers getting faster and more adept at brute force attacks, there can and should be no shortage of security in your web application.
In general, this is a good read for anyone interested in PHP best practices for hashing and salting data: PHP: Password Hashing - Manual
Last edited by chump2877; 07-22-2014 at 07:08 PM.
Help spread the word! Like my YouTube-to-Mp3 Conversion Script on Facebook !! :-)
[Instructional videos and tutorials are also available on YouTube, Dailymotion, and Vimeo]
Get free updates about new software version releases, features, and bug fixes!
♪♪ …Need Web Hosting For My YouTube-To-Mp3 Conversion Software? Check Here !!… ♪♪
ok...Thanks for your link/info. I'll check and study it thoroughly!
I think this post will be helpful - How to Minimize Web Security Vulnerabilities in PHP
Last edited by VIPStephan; 03-10-2016 at 10:24 AM. Reason: removed link
First of all, it doesn’t matter what your guidelines are, so long as everyone understands and sticks to them. I’ve worked on a team where the person in charge preferred to put braces following the expression, rather than on a line all by themselves. I prefer the latter method, but I stuck to the established convention because it made maintaining the whole project much easier.
It cannot be emphasised enough that guidelines are only useful if they are followed. It’s no use having a definitive set of coding guidelines for a joint programming project if everyone continues to write in their own style regardless. You can’t get away with different coding styles even if every team member works on a different section which is encapsulated, because at some point that person will go on holiday, leave, fall under a bus etc. and someone else will have to maintain their code.
If you are running a joint project, you might consider putting your foot down and basically refuse to accept any code that does not conform to your published guidelines, regardless of its technical merit. This may sound somewhat draconian and off-putting to developers at first, but once everyone begins to code to the guidelines you’ll find it a lot easier to manage the project and you’ll get more work done in the same time. It will require a lot of effort from some of your developers who don’t want to abandon their coding habits, but at the end of the day different coding styles will cause more problems than they’re worth.