Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A practical security guide for web developers

github.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: A practical security guide for web developers

#31

Post by fmavituna »

foota wrote: post #29
fmavituna wrote: post #28

Use static source code analysis and dynamic web app scanners. They are easy to integrate into your SDLC, they are not going to replace manual testing or secure development practices but they'll help a lot. They'll pick up tons of stuff for free, they'll remind you best practices. I have a startup (at least it still feels like a startup!) and we are developing a web application security scanner called Netsparker [0].…

Hey I wanted to let you know I thought your slogan on your website was a bit confusing at first "False Positive Free Web Application Security Scanner" I grokked it as "False Positive, free web application security scanner"

Thanks for the feedback. We are actually renewing our website and changing that slogan.

This will be the new message, "Proof Based Scanning" and we tried to explain it in here : https://www.netsparker.com/blog/docs-and-faqs/proof-based-we...

Re: A practical security guide for web developers

#32

Post by minitech »

DrJokepu wrote: post #7

* Don't let HTTP GET requests modify state, ever. It's very difficult to prevent CSRF via HTTP GET. * Session keys are password-equivalents. Hash them with bcrypt or something before you store them. * httponly is not incredibly useful. If the attacker can run JavaScript on your page, you're in trouble.

> Don't let HTTP GET requests modify state, ever. It's very difficult to prevent CSRF via HTTP GET.

Isn’t it exactly as difficult as any other method?

> Session keys are password-equivalents. Hash them with bcrypt or something before you store them.

bcrypt is overkill, especially for something that has to be checked every request; just use any SHA-2 (non-iterated). A session key should be long enough by far to resist brute force.

Re: A practical security guide for web developers

#34

Post by anjanb »

freditup wrote: post #26
buckbova wrote: post #2

Had this SO link saved since probably soon after it was asked 7 years ago. Still relevant and still being updated. http://stackoverflow.com/questions/549/the-definitive-guide-... Includes: - How to log in - How to remain logged in - Managing cookies (including recommended settings) - SSL/HTTPS encryption - How to store passwords - Using secret questions - Forgotten username/password functionality - Use of nonces to p…

The quote at the beginning of the SO question you linked to, one of the top-25 questions of all time, is so ironic given the current state of SO: > We believe that Stack Overflow should not just be a resource for very specific technical questions, but also for general guidelines on how to solve variations on common problems. SO is a great website, but I wonder how much more it could've been if this sort of a page was…

I know what you're saying but they're coming out with Stackoverflow documentation : http://stackoverflow.com/tour/documentation.

Not sure whether this will be the solution that you're looking for. But if you give feedback, maybe, it will happen sometime.

Re: A practical security guide for web developers

#35

Post by onion2k »

CiPHPerCoder wrote: post #12

Please excuse me if this comes across as anything other than constructive criticism, but I don't believe checklists should be used to guide web developers to build secure software. My reason for this belief is that, in my experience, it engenders tunnel vision and what I appropriately refer to as a "checklist mentality". There are developers who believe, "We're immune to the items on the OWASP Top 10, so we're secure…

What you're referring to is the difference between "quality checking", which is the act of checking a product meets acceptance criteria after you've finished building it, and "quality assurance", which is act of putting in processes to guarantee a product is of sufficient quality that you use throughout the build process. A lot of people believe they're doing QA when really they're only doing QC. Both are important.

Re: A practical security guide for web developers

#36

Post by ckastner »

The following PDF focuses on just one specific aspect of security: cryptography, but deserves a mention nonetheless. Configuring various services such that insecure mechanisms are not used is not exactly a trivial task.

https://bettercrypto.org/static/applied-crypto-hardening.pdf

Edit: GitHub repo at https://github.com/BetterCrypto/Applied-Crypto-Hardening

Re: A practical security guide for web developers

#37

Post by aruggirello »

> Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you).

In PHP, I would rather recommend to use password_hash() with its own defaults since it's built-in and designed specifically for this purpose - and quite future-proof. But this is PHP specific.

> [] Destroy all active sessions on reset password (or offer to).

> ...

> [] Destroy the logged in user's session everywhere after successful reset of password.

I believe these are the same. The second one is clearer though.

Edit: clarified

Re: A practical security guide for web developers

#38

Post by pjmorris »

The guide seems to have reasonable technical measures. I would like to see more discussion of risk, both in terms of what is being protected, and of who might be trying to attack. For example, you might wish to be more careful when developing a bitcoin wallet than when tracking baseball scores.

Shameless plug: I've been working on a somewhat less practical guide to software development security practices [1]. Even more shameless plug: I'm currently running a survey of security practice use in software development [2], and would welcome participants who work on open source projects.

[1] http://pjmorris.github.io/Security-Practices-Evaluation-Fram...

[2] https://ncsu.qualtrics.com//SE/?SID=SV_1HdQOa2lfX57vkF

Re: A practical security guide for web developers

#39

Post by ownagefool »

yeukhon wrote: post #4

The first thing jumped out is: Store password hashes using Bcrypt (no salt necessary - Bcrypt does it for you) A better approach would be recommending storing password with password-based key derivation functions (recommendation: scrypt or bcrypt). I don't want to start the whole debate of scrypt vs bcrypt, GPU vs FPGA here (not qualified and we keep repeating the conversation every time the vs is on the table). - Wh…

If you, as a developer, jump ship to the new shiney without understanding the security story then it is your fault, irregardless of what promises were levied by your new tool.

That doesn't mean that bad defaults are fine, as part of the community we should all be fixing these, but knowing about these things are part of the job and you should not absolve the framework jumpers of their responsibilities.

More importantly, companies should pick their technical leaders better. That they don't is often why they end up in a mess.

Post reply on HN