PHP v7

Few security questions for php gurus.

Sanitizing user inputs (am i missing anything?)
- mysql_real_escape_string on the string before inserting it into your SQL query (before DB entry)
- htmlspecialchars on the string before displaying it to the user (displaying to user)
- Using PDO for DB Insert


2nd question:
I'm passing variables to another page. So like mypage.php?itemview=13. I'd like to encrypt the var so the users can't modify. Is session the way to go? I found this AES ecnrypt function..

function encrypt_decrypt($action, $string) {
    $output = false;
    $encrypt_method = "AES-256-CBC";
    $secret_key = 'This is my secret key';
    $secret_iv = 'This is my secret iv';
    // hash
    $key = hash('sha256', $secret_key);
    
    // iv - encrypt method AES-256-CBC expects 16 bytes - else you will get a warning
    $iv = substr(hash('sha256', $secret_iv), 0, 16);
    if ( $action == 'encrypt' ) {
        $output = openssl_encrypt($string, $encrypt_method, $key, 0, $iv);
        $output = base64_encode($output);
    } else if( $action == 'decrypt' ) {
        $output = openssl_decrypt(base64_decode($string), $encrypt_method, $key, 0, $iv);
    }
    return $output;
}

10/28/2017 7:27:41 AM

mysql_real_escape_string isn’t in php 7 (its old) and doesn’t work with pdo anyway, just use pdo binds

10/28/2017 8:25:21 PM

^+1

[I'm pretty sure you're more technical than this post... but I'm used to people complaining on the internal stack overflow...]

PDO, without a doubt, is the way to roll.

In the old days mysql operations were basically sent to the DB engine as a simple string. Just like you were sitting at the terminal mashing it all in manually. SQL Injection at this level is pretty simple: by inserting command terminators ( ; ) into a variable you could inject random commands and have the db execute them.

Part 1 of defending against that was escaping strings. Essentially attempting to make sure command terminators were sent escaped so the engine interpreted them as part of a string and not part of the command. Ultimately people became more and more creative - sending random-looking strings that were eventually translated to something bad - it was a miserable situation. Sometimes OS'es would differ in how they handled this process, and while mysqli and escaping can be reasonably secure (with help)... why.

PDO solves this by completely separating the command sent and the information sent. Effectively it opens two channels, sends your query on one with data markers, and the data on the other. So mysql knows everything within a data marker is string in advance (because you sent the hint PDO PARAM_STR with it) - it doesn't have to interpret as it goes along blindly. SUPER conveniently it also allows you to change database engines with minimal effort because the "cleaning" is not locked to a database engine. Instead of building a fancy cleaner, PDO removes the need for it to be cleaned.





It sounds like you're confusing sessions a little bit with cookies. Cookies are stored on user machines - users can generally read everything that's in it, and can replace that data and send back whatever they want. Nothing important should be stored there. Unless your environment is insanely large, or you're building something stateless like an API, what you want is a session - freak all that encryption noise, that stuff is expensive. At least consider using your new PDO database skills instead of encrypting data thats going to leave your box to a user.

Think of sessions kinda like a mom and pop butcher shop. You get a number that says you're number 22, and you request 2lbs of steaks, 1.5lbs of chicken, and 5 bratwurst. The butcher generates a ticket with a 22 on it and the correct lb values and cost of each item, then walks all your stuff up to the register neatly wrapped in paper and lets someone cash you out. This is a session. If you were writing the ticket yourself you could write down whatever you want and possibly pay like 50 cent for 10lbs of meat. That's a cookie.


Sessions solve two problems. One, is speeding up authentication with your server. Good authentication is relatively expensive - running hashes, adding salt, running more hashes, checking a database, comparing this and that - it's exhausting. Two, is storing/caching temporary data server side - again to speed up transactions with your server.

Long story short it works similarly to the butcher shop. User sends their credentials and authenticates who they are with the server. Once you know it's them, issue them a session id (session start) - just like issuing id 22 in the shop. Checking for session existence is your security check - if it's not there, redirect to login. (edit: technically you could issue them a session ID immediately, as soon as they hit your site if they don't have one - just be sure to extend the security check for a session-based isAuthed flag.)
This id will be stored by the browser and sent in the background to your server attached to every request (PHPSESSID in debug tools.) You (the butcher) now have a ticket (a small file on your server) that you can store whatever information you need that the user will never see. Write "ugly hair", whatever you want into the session... the only thing the user possess is the key, the id 22 - none of the data. Putting data in session can prevent calling a database, prevent building complex information again, etc.

Only real caveat is it pretty much fully depends on the client - there needs to be something to accept the key and send it with every request. Browsers are usually this vehicle, but that might not be the case for an API. The other caveat is that session keys are very complex, but if you have mad traffic you can conceivably create a collision. Something like 50K concurrent sessions on a single box should start to worry you. Last thing I'll mention is that they're effectively tiny files. If you're on the worlds worst host, you could run out of inodes, but that's super unlikely.




This should not be confused with session storage in browsers. Session storage for browsers gives you a few megs of local space to store random data you need kept in browser, not on server. Not even remotely similar - session storage is never sent to the server (by default). Think more like scratch space for calculating something or holding an image file temporarily to make a thumbnail, etc.



[Edited on October 28, 2017 at 10:49 PM. Reason : editor trying to make smileys where they shouldn't be]

10/28/2017 10:38:58 PM

Good stuff. thank you.

I haven't done PHP in like 8 years so good to know. I think my old employer never upgraded my old app from like 8 years ago and someone dropped the database lol.

Quote :

" At least consider using your new PDO database skills instead of encrypting data thats going to leave your box to a user. "

I agree - I thinking about making owners and checking if they actually own the itemID vs doing the encyrption.

I was also thinking about adding roles eventually for my Session. Limiting pages and such and force re-direct if they try to access.

10/29/2017 11:03:55 AM

Quote :

"I thinking about making owners and checking if they actually own the itemID"

I... I feel like you should start there. If you're avoiding some kind of authentication and/or long term storage (maybe like a signup form over multiple pages) you have some options without a database.

The simplest is store it in the browser. Build your pages to "appear" like pages with some divs and hiding trickery with javascript, but it's one giant form and send it all at once. If you must pass data between pages, you can still store it in the browser using sessionStorage or localStorage in the HTML5 spec.

Sending to the server, the session is the easiest way to store things. You can open one at the start and hold all their data as you go along. However; they're temporary. If you need it kept, viva database.

10/29/2017 10:35:25 PM