Spy der Mann's Journal: Dangerous PHP security mistakes

The following mistakes are presented in no particular order, because even one of them can result in your web application being hacked.

Error #1: Not requiring login in your other php pages.

If a user can access directly the other php pages in your application, it's probable that some variables aren't initialized properly - this could allow a malicious user to spot SQL errors, injection attacks, etc. A simple include() to check the session variables can prevent this problem.

Error #2: Enabling read-access for anything but the front-door of your app (i.e. image gallery, included files, etc)

EZPhotoSales software had a bug in which users could access people's private images. This means invasion of privacy to say the least. To prevent this, you can use PHP downloaders using fpassthru() or fopen + echo. This way only logged in users can view the pages, and you can implement more security measures.

For included files, add an htaccess preventing read access from anyone. My favorite trick which involves customized php error pages, is making the included directories stealth: Use mod_rewrite to redirect to a 404 page. This way the forbidden directories will be invisible to an attacker: He won't see a 403 page, but instead will think that the directory wasn't there.

Error #3: Passwords in plain text.

Many wireless access points aren't secured, and this has helped hackers leech over other people's connection. But this means they can sniff the passwords sent without encryption, as they are actually tapping over the victim's internet connection. This is true for both php password pages, and for Apache basic authentication. If you use a random salt + hashed password for authentication instead, someone sniffing over the authentication won't be able to log in. However, after you log in, he could hijack the session cookies (wireless access points share the same IP), so https is a MUST these days.

Error #4: Not changing the session id after login.

A malicious user could copy/paste the url from a login screen from the victim, if they share the same physical space (i.e. at work). Assumming that after log in all communications are SSL-encrypted, usually most apps are unencrypted for the login screen. If you don't regenerate the session id after log in, you're allowing the malicious user to hijack the session id and pose as the victim.

Having an IP-address check helps a lot to prevent this and adds tighter security to the application (for clumsy users who forget to log out), but ISPs like AOL make this impossible to enforce (you could also add a checkbox for the
login page like "Don't check my IP, I'm using a crappy ISP".

Error #5: Using cookies to store delicate information
If your web host doesn't allow https, you're in a lot of trouble. Cross-site scripting (XSS) can enable an attacker to obtain the cookie variables, or they could be eavesdropped if the attacker has access to the victim's network. It's much worse if the cookie variables are used for authentication. Now, isn't that special? Saving the username and password in the cookies.

As a rule of thumb, ONLY store the session id in the cookies. Save the rest in the $_SESSION array.

Error #6: Trusting AJAX calls.
No, no, and no. Always restrict privileges for AJAX, remember the variables can be forged by an attacker. If you don't check your data before passing it to an SQL query, you could be the victim from an SQL injection attack. Always follow murphy's law: What can go wrong, WILL go wrong. And this is true for GET and POST variables, as well.

An important note about AJAX: Always follow the multi-tier model (interface-business-data). AJAX is *ONLY* the interface. Do not let AJAX procedures have access to the data tier - a forged AJAX call can result in your database be modified freely! Validate AJAX requests, check the session id, login, user's privileges before doing any operation.