• 4
name

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191

Backtrace:

File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

What security issues should I look out for in PHP

I just starting out learning PHP, I've been developing web apps in ASP.Net for a long time. I was wondering if there are any PHP specific security mistakes that I should be looking out for.

So, my question is what are the top security tips that every PHP developer should know?

Please keep it to one tip per answer so people can vote up/down effectively.

(In no particular order)

  1. Always check that register globals are OFF
  2. Always check that magic quotes are OFF
  3. Make sure you understand SQL injection attacks
  4. Turn OFF error reporting in production

EDIT: For the "newbies" out there this is a basic why (and since I have time to explain this):

  1. Register globals is an aberration. It's the ultimate security hole ever. For example, if register_globals is on, the url http://www.yourdomain.com/foo.php?isAdmin=1 will declare $isAdmin as a global variable with no code required. I don't know why this "feature" has made it's way to PHP, but the people behind this should have the following tattooed on their forehead: "I invented PHP Register Globals" so we can flee them like pest when we see them!

  2. Magic quotes is another dumb idea that has made it's way to PHP. Basically, when ON PHP will escape quotes automatically (' become \' and " become \") to help with SQL injection attacks. The concept is not bad (help avoid injection attacks), but escaping all GET, POST and COOKIE values make your code so much complex (for example, have to unescape everytime when displaying and data). Plus if one day you switch this setting OFF without doing any change to your code, all your code and/or data is broken and (even more) vulnerable to injection attacks (yes even when ON you are vulnerable).

  3. Your databse data is your most valuable thing on your site. You don't want people to mess with it, so protect yourself and read things about it and code with this in mind.

  4. Again this can lead to security concerns. The error message can give hints to hackes on how your code works. Also these messages don't mean anything to your visitors, so why show them?

  • 17
Reply Report
  • 12
Reply Report
    • It isn't that session_start() is inherently weak, it's that session IDs can be "fixated" in various ways (querystring, post parameters, or if you can control cookies), which can give a malicious attacker complete access to an authenticated system. Taking steps to prevent this (e.g., disallowing sesison IDs to be set by POST and GET, rotating session IDs on certain events such as login and purchase) are simple ways to prevent this sort of attack. My question is, in what world is session_start() with no other Session Fixation protections considered adequate protection?
      • 2
    • -1 for md5 used in passwords. Overly simplistic answer, and session fixation isn't an issue if you use session_start(). but you just linked to google like a troll.
    • @Michael, Where did I ever recommend using MD5 for anything ever? More importantly, given the myriad of potential problems that can arise, what would be more worthwhile, me trying to reproduce hundreds of documents and thousands of man-years worth of research in one SO answer, or linking to enough resources to get you started with the right keywords? Furthermore, I also link to a huge hand-written article that I wrote, as well as an M.I.T. paper on Client Authentication, since they are more specific sources than just google for their respective topics.
    • Just read something you said: session fixation isn't an issue if you use session_start()? Do you know how PHP's session model works? That is PRECISELY the problem with it. Maybe you were thinking of session_regenerate_id()? Although, that also introduces Race Conditions in environments where multiple requests may be firing at once (AJAX, for one). I challenge that your suggestion to "just use session_start()" is the 'Overly Simplified' answer of the week in terms of PHP security!
      • 2
    • Your password storage model is defiantly wrong. Blowfish is really old, use twofish. Block ciphers shouldn't be used for passwords its a violation of CWE-257 cwe.mitre.org/data/definitions/257.html. Currently the only NIST certified message digest function for passwords is the sha2 family. Sha256 is a good choice.

here is a link of good PHP security programming practices.

http://phpsec.org/

Most of the security issues revolve around user input (naturally) and making sure they don't screw you over. Always make sure you validate your input.

http://htmlfixit.com/cgi-tutes/tutorial_PHP_Security_Issues.php

  • 8
Reply Report
  1. Always sanitize and validate data passed from the page
  2. In conjunction with #1, always properly escape your output
  3. Always turn display_errors off in production
  4. If using a DB backend use a driver that supports/emulates prepared statements and use without prejudice :-)
  • 7
Reply Report
    • XSRF has nothing to do with escaping. If you do everything on this list you'll can still get hacked to tears.
    • @Michael: I didnt say this was the be all end all of the list nor did specifically mention anything about XSRF. In fact every recommend on this list up until now has good info and cautionings.
    • Yeah you won some points in my book for parametrized quires. But every answer for this question is far too simplistic. Its really bugs me that all people think about is xss and sqli.

Language Vs Programmer. You can write the most serious vulnerability and you won't get a warning or error message. Vulnerabilities can be as simple as adding or removing 2 characters in your code. There are hundreds of different types of vulnerabilities that affect PHP applications. Most people think of XSS and Sql Injection because they are the most popular.

Read the OWASP top 10.

  • 5
Reply Report

Most of the security issues related to PHP come from using unparsed "outside" (GET/POST/COOKIE) variables. People put that kind of data directly into file paths or sql queries, resulting in file leakage or sql injections.

  • 1
Reply Report
  1. Always Close you SQL Connection.
  2. Always Release SQL results.
  3. Always Scrub all variables your putting into a database.
  4. When deleteing or dropping from sql use limit 1 just in case.
  5. When developing make sure you have a lock on things to keep the undesirable out. If its open and you know not to load the page right now because it could break something, doesn't mean other people do.
  6. Never use Admin or Root as your server log in name.
  • 1
Reply Report

Whenever possible, use prepared statements (tutorial. It's almost a must whenever dealing with user input (I say "almost" because there are a few use cases where they don't work), and even when not dealing with input, they keep you in the habit. Not to mention they can lead to better performance, and are a LOT easier, once you get into the swing of things, than piecemeal sanitizing.

  • 1
Reply Report

Warm tip !!!

This article is reproduced from Stack Exchange / Stack Overflow, please click

Trending Tags

Related Questions