4 ms·

Granting one understands, generally, how these vulnerabilities work (read up on that site) - what would then be a good next step? Oftentimes these small compan

by toufka 12y ago

Granting one understands, generally, how these vulnerabilities work (read up on that site) - what would then be a good next step? Oftentimes these small companies are focused on getting the data-flow to work and have not coded in all the edge cases. What are reasonable (easy would be nice too) steps one can take to help mitigate the most vulnerable edge cases? Or is it something that should just immediately be hired out just before you want to go live?

steakejjs 12y ago
I think OWASP does a good job explaining this stuff if you know how to build a web-app, you should be able to understand the vulns (they give PoC code and examples). OWASP could be doing a lot more but their PoC and descriptions are pretty good. Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi? Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.
raesene4 12y ago
Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on. Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues. Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...
- krapp 12y ago
  This is doubly true for PHP. Upgrading an (already likely secure) database class in a framework that uses PDO is a lot easier than changing a thousand calls to mysql_query after the fact. You don't have to worry about wrapping every echoed variable in htmlspecialchars() when you're already using twig. PHP developers keep running afoul of what are already mostly solved problems. Imposing a bit of structure and modularity now will make responses to issues easier later. Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun. And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.

by toufka 12y ago

steakejjs 12y ago

I think OWASP does a good job explaining this stuff if you know how to build a web-app, you should be able to understand the vulns (they give PoC code and examples). OWASP could be doing a lot more but their PoC and descriptions are pretty good. Your next step is to think about how you will be preventing them. An example, If you are writing a PHP site without a framework, how will you generate, validate, and store CSRF tokens? How will you filter output? How will you architect your web-app to prevent SQLi? Security consulting is ridiculously expensive and I've seen companies pay a lot to get told very little. If you want to run security concerns by me, I am free to contact.

raesene4 12y ago

Best advice I could provide if the devs aren't too knowledgeable on application security, is use a framework where possible, know where it's likely to fail you and focus there and then make sure you stay on top of patching all your framework components to catch vulns in that layer So for example rails handles basic things like SQL injection, XSS in standard forms fine, then you can use devise or similar for authentication and get a reasonable level of security. What you're left with are areas like authorisation which tends to be app. specific so still requires work, but you probably have less to focus on. Also watch out for what I'd call "dangerous" functionality, things like file uploads or user generated content where you want users to enter HTML tags but still avoid XSS. Things like that need specific consideration to avoid common security issues. Of course if you're doing something that will attract real bad guys (anything to do with payments, anything to do with bitcoin, anything to do with Intellectual property management etc) then I'd strongly recommend getting an app security person on staff as soon as you can 'cause you will get attacked probably sooner rather than later...

krapp 12y ago
This is doubly true for PHP. Upgrading an (already likely secure) database class in a framework that uses PDO is a lot easier than changing a thousand calls to mysql_query after the fact. You don't have to worry about wrapping every echoed variable in htmlspecialchars() when you're already using twig. PHP developers keep running afoul of what are already mostly solved problems. Imposing a bit of structure and modularity now will make responses to issues easier later. Although the downsides of this are the possible vulnerabilities in the framework itself (as well as the potential learning curve and lock-in) there are likely to be more people using, and finding, those vulnerabilities than would be in your quick-and-dirty handrolled quasiframework. Even if the latter is more fun. And if you're on shared hosting... umm... you should probably reconsider that. If that's not likely to happen soon, then database-driven sessions, regular backups and SSL are a must.