As I’m trying to get back into some more regular article writing for the websec.io security tutorial site, I thought I’d ask on Twitter for some of the things people might be interested in reading. I thought I’d gather them all up and share them here (since Twitter is sooo good at tracking this kind of thing…). There were some good responses and some things I hadn’t thought about yet:
> Top 10 pitfalls and how to avoid them. @calevans
> how to actually filter input and escape output correctly. @skoop
> I’d like the ability to answer to the question “Is it safe?” with confidence. @AmyStephen
> Data sanitization, escaping, and authentication. @codeguy
> how to test for secure code. @scottmattocks
> One of my largest stumbling blocks has been learning how to write proper (library-less) templates in a secure and flexible manner. @mkmcdonald
You can see all of the responses here. There’s a few articles related to these posted already:
- OWASP Top 10: XSS and Broken Auth/Session Management
- Effective Validation with Respect
- the Core Concepts series
- a series covering Two Factor Authentication
If you have any other suggestions let me know!
blog.phpdev 
Sounds like a nice list. Especially the “Input filtering/output escaping the right way” and testing secure code is something I’d look forward too.
Probably ‘how to answer “is it safe”‘ too!
LikeLike
A test script to check for vulnerability in our own app will help a lot.
LikeLike
What I am somewhat amazed by is the amount of basic security lessons that are ignored in web development.
Almost every open source app I know stores user information[userid, username, password, email address, and basic user profile info – for some definition of basic] in a single record. Then they put a lot of effort into picking just the right password hash function to “secure” data that never should have been there to begin with! This is an old school unix “oppsie” with a tried and tested solution. Never store passwords in the same place as other data that will be needed by many subcomponents of an application. Passwords should be stored in their own area with strict access controls. For mysql, this means put them in their own table at a minimum so an accidental user dump doesn’t expose the data. Preferably, the table should only be accessible by a seperate mysql userid which can only access that table – and then create a stored procedure which retrieves a single record and use that to authenticate logons.
That avoids a whole slew of sql injection attacks – and it’s a well tested, decades old solution.
Yet PHP app after app repeats the mistakes of the past rather than learn from them.
LikeLike
Agreed – it’s a pretty common practice that’s not helped by the multitudes of articles and tutorials out there preaching the same things. It’s a tricky thing because with beginners, there’s a balance between introducing them to the topic and not getting too wrapped up in the more correct password storage methods. I’m a big advocate for teaching people how to do things right the first time, though, and not pandering to the lowest common denominator.
LikeLike