Tagged #php

SQL injection is one of the oldest web vulnerabilities around, and it still turns up constantly. The reason is simple. The vulnerable version of the code is the most obvious way to write it. Picture a search box that looks up a user by email. The natural first attempt in PHP looks like this: It works. Type in an email, get a user back. The problem is that you've taken text from a stranger and pasted it directly into a command your database will run. The database has no way to tell which parts you wrote and which parts the visitor wrote. It just sees one string of SQL. So if someone types…

If your app has user accounts, at some point you're storing something derived from people's passwords. The question isn't whether your database will ever leak. Plan as if it will. The question is how much damage that leak does. Good password storage turns "attackers have everyone's password" into "attackers have a slow, expensive puzzle per user." That gap is huge, and it mostly comes down to picking the right function and not getting clever. Hashing, not encryption First thing to get straight. Encryption is reversible: anyone with the key can get the original back. That's exactly what you…

Every year or so somebody declares PHP dead, and every year a huge chunk of the web keeps running on it anyway. WordPress, Wikipedia's MediaWiki, Drupal, a lot of the shops and forums and little business sites you use without thinking about it. Dead languages don't usually power that much stuff. I get where the reputation came from. Old PHP was rough. The standard library had inconsistent function names and argument orders that you just had to memorize. Tutorials taught people to paste user input straight into SQL queries. Lots of code was one giant file mixing HTML, database calls and…