0

Possible Duplicate:
What’s the best method for sanitizing user input with PHP?

I know similar questions have been asked multiple times here, and I've spent some time reading all of them, but I am still not confident if my application is going to be secure...

The website I am building allows users to post things into a database, edit their own postings, search for other postings, and display postings from other users. Clearly, there is a whole bunch of user input and form data and what not, which I have to make sure is secure.

So here's how my process currently works:

  1. users input their data into HTML forms, which are converted into $_POST data.
  2. a posthandler.php file converts all $_POST data into $_SESSION data
  3. the $_SESSION data is converted into $this-> class variables
  4. the $this-> class variables are used in the mySQL query and entered into the DB
  5. from the DB the data is displayed back in HTML.

What measures do I have to take in which of those steps in order to insure the security of my website? (preventing code injection and XSS)

For now this is what I am thinking, please correct me if I am wrong:

  • For 1. I have no control, the data is completely vulnerable.

  • Therefore in 2. I have to check if the data matches certain patterns, which I expect (check if it's numeric, check if it's a date, check if it's letters only, check if it's a value from an array which I provide, use regular expressions, ... ) This way I can prevent for example if I expect a value between 1 and 10, and someone says "'--DROP table;" instead that I have already made sure these fields are secure. Of course fields, which are not as restrictive like text boxes where users can type messages are still vulnerable.

  • For step 3. there shouldn't be anything I need to do, if I did everything correct in the step before, right? An attacker shouldn't be able to change the SESSION data or the class variables, unless there is a major security breach on the server side, for which my hosting provider should be responsible, correct?

  • In step 4. where I do my query, I need to escape the data with mysqli_real_escape_string() to make sure the data is not handled as a command.

  • And in step 5. I plan on converting every special character into their respective HTML code snippet. All " are going to be converted to " for example.

Are there any additional security measures /filters I should apply within each step?

What if I make a mistake in step 2.) or I am unable to find a regular expression for a field. I just convert from $_POST to $_SESSION without further validation. Will it save my butt to use mysqli_real_escape_string() during the query and to filter all characters before they are displayed in the browser?

I look forward to your insight!

Community
  • 1
  • 1
oliver_siegel
  • 1,666
  • 3
  • 22
  • 37
  • 6
    1) prepared statements. 2) prepared statements. 3) prepared statements. Encoding html prior to embedding in the db gains you nothing, and just makes things harder later on when you retrieve for display. – Marc B Oct 31 '12 at 14:56
  • for step 5, I hope you don't mean to do that manually - you should be using htmlspecialchars. Also, this question, while important, just has to be a duplicate of a duped duplicate and I bet you could find the answers by searching. – JAL Oct 31 '12 at 14:59
  • The is a stackexchange site named codereview you might have more success there. – Iznogood Oct 31 '12 at 14:59
  • 1
    Escape your input, encode your output. There is nothing else. Other security measures are useless, false security. If you do not properly escape input before it hits the database and output before it hits the browser, your security is broken. How you do this varies from language to language and framework to framework. – user229044 Oct 31 '12 at 15:01
  • Checking that a date is a date in step 2 isn't relevant *from a security standpoint*. The actual data doesn't matter, all that matters is that it is escaped before it is used as part of a database query. You need to read about PDO. Avoid `mysqli*` functions. Your step 5 should happen on subsequent requests, when you recall data from the database. – user229044 Oct 31 '12 at 15:08
  • @Marc B: I didn't say I was encoding before I entered into the db. – oliver_siegel Oct 31 '12 at 15:28
  • @meagar: The question you posted asks for a magic bullet, that fixes everything, I am specifically asking for what works within each step. So u say I don't have to be concerned about anything bad happening when I have unescaped user date in my POST, SESSION or CLASS variables? Only when I actually send it as a query to the DB or when I display it in the browser? Also I thought checking e.g. a date is relevant to prevent someone attempting injection. If I only allow numbers, no one can ever say "DROP TABLE" because it's not a number, right? mysqli can do prepared statements, why avoid it? – oliver_siegel Oct 31 '12 at 15:35
  • @JAL: like I said, I tried searching, but haven't found any satisfying results. :-( htmlspecialchars only translates so few characters into html, I feel better writing my own function that takes care of other characters as well. May I ask why you suggest to use htmlspecialchars? – oliver_siegel Oct 31 '12 at 15:43
  • 1
    @user1615297 What works at each step is irrelevant. There is only *one* step, and that is escaping data before it becomes part of your query. This should happen outside your application code, at the last possible second, within your database abstraction layer (ie, PDO). It's not OK to roll this by hand anymore. It isn't 2005. Use PDO and move on to the more important parts of building your application. – user229044 Oct 31 '12 at 15:45
  • I agree with meagar: use PDO and prepared statements, and then escape your output. That's all you need to do. Sometimes I sanitize input just for kicks, too like when I know something should be an integer, or only certain characters, etc. – JAL Oct 31 '12 at 19:38
  • @Marc B nailed it right off the bat, no further answer is required. – rook Oct 31 '12 at 20:20
  • htmlspecialchars is intended for this purpose and written and maintained by people with prior experience, and more time and feedback to make it right than you. Never roll your own ANYTHING if you don't know what you're doing, and even then... – JAL Nov 01 '12 at 14:36

0 Answers0