7 ms·

What should every programmer know about security?

162 points by napolux 15y ago

ryanherman 15y ago
I ended up taking the backtrack pentest training to gain an update of what hacking has become. I highly recommend it.
deleted 14y ago
[deleted]
rudhir-secpanel 14y ago
http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html http://www.behind-the-enemy-lines.com/2012/04/google-attack-... Interesting post which showed how badly configured linkages between private google docs and S3 caused an accidental DoS.
rollypolly 15y ago
I would add this to the suggested reading list: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
- ecesena 15y ago
  I've found this list really valuable. I believe that there are two main security objectives while designing a new system: one is to protect the system itself against attackers, another one is trying to limit damage (especially data exposure) in case an attack actually happens. Nowadays I think the first one is a must... from this point of view I wouldn't say it's important to check user input... it's a must! (while building a system, I don't usually think how can I check user input, rather how can I assure that my system will always check user input). But since we can fail, the second objective is really important too and many design choices should really be done with security coming before functionality. A simple example is password storage. The guidelines are good in pointing to bcrypt (another fine solution is pkcs5), but often just a hash function is used (sometimes even md5 that we can no longer consider a robust hash) or the salt is replaced with something which is not random (e.g. timestamp). These bad design choices could lead to easier password recovery. Another aspect that I try to enforce in my neighborhood is protecting sensitive user data at least with user password. Of course this requires the user to enter her password every time the data must be accessed, but often this is already the case (think to a payment, wouldn't you ask the user for her password before doing it? So why her payment data shouldn't be protected?)
kirinan 15y ago
Since this is my specialty, I figured I'd put my 2cents in on hacker news, and repost it on stack overflow later. So to begin some tools that you should use for testing your code: Burp tool suite (Pen Testing) BackTrack Linux Distro (has all kinds of tools, wont go into them, but download and it can be used to really cause havoc on your apps) These tools allow you point programs towards your application and see if they are vulnerable to any kind of attacks, including XSS and SQL Injection (among a lot of others) Engineers should also read the OWASP site, which has the OWASP top ten. It also has other tips and tricks about how to secure against different attacks. If you ever have a security question, this site has a lot of secure examples for different code. As the top comment on stack overflow says, never trust your users. That means never allow your users to do things that you don't want them to. If you allow them to deviate from the structure of your program in any sense, someone will find a way to abuse the privilege. This is the key to good security. Some Tips I'll give you: 1 ) Validate all input 2 ) Control Access to everything 3 ) Use secure application keys to ensure that people can spoof requests from different browsers 4 ) Use Multi Factor Authentication whenever its possible 5 ) Never ever pass any values from the server that should leave to the client. Even if it is hashed, I can break it using tools. Valuable data = Server side Public Data = Client safe If you have any other questions, feel free to post them and I'll try my best to answer them or find you an answer.
- kibwen 15y ago
  Information security is a topic that I'm very interested in, but it's such a large area that I don't know even where to start. In this field especially, "learning by doing" seems an extraordinarily bad idea. You say this is your speciality; how did you acquire it? Are there any online courses, good books, or useful (i.e. non-bullshit) certifications that you can recommend?
  - smu 15y ago
    It has become a lot easier to "learn by doing" without breaking any rules. If you are looking at web application security, there are a number of "simulation" games. The first that come to mind are Damn Vulnerable Web App (http://www.dvwa.co.uk/ http://www.dvwa.co.uk/), The Hackme Bank (http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx http://www.mcafee.com/us/downloads/free-tools/hacme-bank.asp...) or OWASPs WebGoat (https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project https://www.owasp.org/index.php/Category:OWASP_WebGoat_Proje...) DVWA is probably the best choice for somebody with no prior knowledge. A quick google search on "dvwa walkthrough" will get you started.
FuzzyDunlop 15y ago
I think it'd be interesting to highlight some vaguely security-related measures that might make it less simple for attackers to shut down your site just by using it normally. I'm not so sure it's relevant to the SO question, mind, as it's more in line with optimisation than anything. This might include: * Using a caching layer to store and re-use the results of complex, infrequently changing queries, instead of querying the database on every request. * Using a message queue to handle the processing of certain things in the background. If you have an upload form that then manipulates or processes the file in some non-trivial manner, add it to the queue. The queue can drop messages or jobs if it gets too big. I only say this having developed some projects where holding the refresh key down for a few seconds on pages with lots of queries (along with the hundreds Drupal makes anyway) could crash MySQL. As could using a separate form that sent emails and processed images on-the-fly. Best not to present attackers prime opportunities to DOS your site.
- napolux 15y ago
  Interesting! :)
tptacek 15y ago
I am wary of software security advice that leads with "don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could phrase this less tactfully as "Validate user input? No shit? Now what?" Here's some software security advice I'd like to offer, as a software security practitioner to the startup stars and the Dr. Drew Pinsky of HN (ducks): * Plan to update your platform software at inconvenient times. Dry-run your update process, so you know it will work on no notice. I personally believe you should also avoid your OS's packaged versions of things like Apache and nginx; having a known-working source build gives you control of when and how you'll apply patches; it's something you should be able to do easily. * Put someone on your team in charge of tracking your dependencies (C libraries, Ruby gems, Python easy_install thingies) and have a process by which you periodically check to make sure you're capturing upstream security fixes. You should run your service aware of the fact that major vulnerabilities in third-party library code are often fixed without fanfare or advisories; when maintainers don't know exactly who's affected how, the whole announcement might happen in a git commit. * Use TLS to encrypt data in motion and use GPG to encrypt data at rest, and don't do any other kind of crypto. GPG blobs are large and expensive looking, but getting custom crypto right is also very expensive. * Stay on your platform's "golden path" for web security issues. Rails developers should default-whitelist ActiveRecord models, enable CSRF protection, and avoid "html_safe-ing" strings so that the maximum amount of code inherits default protections against mass assignment, XSS, and CSRF. Anything you customize will probably bite you in the ass. Keep your code boring. * Triple check any piece of code that "shells out" to command line tools. By "triple check": have a process by which three signoffs are required to merge any such code into the deployment branch. * Be extraordinarily wary of library code for web apps that includes "native" C/C++ code. Very popular C library code for modern web platforms has been found susceptible to basic memory corruption issues, because the kinds of people that look for memory corruption bugs don't usually think to troll Github for Ruby, Python, and PHP code with native backend code; terrible bugs can thus stay latent for years in code you can point a URL to and read. * People will hate me for saying this but I'm here to offer honest advice: prefer almost any modern language to PHP or Perl. I don't know what to tell you other than that PHP and Perl apps fare worse on security assessments than everything else. * I have more than once recommended that people who are very very concerned about platform security (ie, about the likelihood that there are memory corruption bugs in their language stack) use JVM languages. * Do your admin stuff out-of-band. Write a separate admin app (bonus: the admin app can look shitty, and so is less expensive to maintain) that requires a VPN connection to access. Avoid special-privilege accounts in your normal apps. From years and years of experience working with startups: this is something you will mess up on. * Triple-check code that handles direct file uploads and downloads. The filesystem introduces a new namespace, so upload/download code needs to juggle different privilege and authorization domains to handle it. We see fewer problems at companies that dump blobs with opaque names into S3 than we do with apps that have a file repository with named files. * HAVE A SECURITY PAGE FOR YOUR APP. Have that page very cordially invite people to submit security flaws to an email address at your site; provide a PGP key for it. If I was maintaining a commercial app, I'd put a phone number on that page too. If you don't have this page, you should know that you are tacitly inviting people to report security flaws to Twitter.

162 points by napolux 15y ago

ryanherman 15y ago

I ended up taking the backtrack pentest training to gain an update of what hacking has become. I highly recommend it.

deleted 14y ago

[deleted]

rudhir-secpanel 14y ago

http://www.behind-the-enemy-lines.com/2012/04/google-attack-how-i-self-attacked.html http://www.behind-the-enemy-lines.com/2012/04/google-attack-... Interesting post which showed how badly configured linkages between private google docs and S3 caused an accidental DoS.

rollypolly 15y ago

I would add this to the suggested reading list: https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines

ecesena 15y ago
I've found this list really valuable. I believe that there are two main security objectives while designing a new system: one is to protect the system itself against attackers, another one is trying to limit damage (especially data exposure) in case an attack actually happens. Nowadays I think the first one is a must... from this point of view I wouldn't say it's important to check user input... it's a must! (while building a system, I don't usually think how can I check user input, rather how can I assure that my system will always check user input). But since we can fail, the second objective is really important too and many design choices should really be done with security coming before functionality. A simple example is password storage. The guidelines are good in pointing to bcrypt (another fine solution is pkcs5), but often just a hash function is used (sometimes even md5 that we can no longer consider a robust hash) or the salt is replaced with something which is not random (e.g. timestamp). These bad design choices could lead to easier password recovery. Another aspect that I try to enforce in my neighborhood is protecting sensitive user data at least with user password. Of course this requires the user to enter her password every time the data must be accessed, but often this is already the case (think to a payment, wouldn't you ask the user for her password before doing it? So why her payment data shouldn't be protected?)

kirinan 15y ago

Since this is my specialty, I figured I'd put my 2cents in on hacker news, and repost it on stack overflow later. So to begin some tools that you should use for testing your code: Burp tool suite (Pen Testing) BackTrack Linux Distro (has all kinds of tools, wont go into them, but download and it can be used to really cause havoc on your apps) These tools allow you point programs towards your application and see if they are vulnerable to any kind of attacks, including XSS and SQL Injection (among a lot of others) Engineers should also read the OWASP site, which has the OWASP top ten. It also has other tips and tricks about how to secure against different attacks. If you ever have a security question, this site has a lot of secure examples for different code. As the top comment on stack overflow says, never trust your users. That means never allow your users to do things that you don't want them to. If you allow them to deviate from the structure of your program in any sense, someone will find a way to abuse the privilege. This is the key to good security. Some Tips I'll give you: 1 ) Validate all input 2 ) Control Access to everything 3 ) Use secure application keys to ensure that people can spoof requests from different browsers 4 ) Use Multi Factor Authentication whenever its possible 5 ) Never ever pass any values from the server that should leave to the client. Even if it is hashed, I can break it using tools. Valuable data = Server side Public Data = Client safe If you have any other questions, feel free to post them and I'll try my best to answer them or find you an answer.

kibwen 15y ago
Information security is a topic that I'm very interested in, but it's such a large area that I don't know even where to start. In this field especially, "learning by doing" seems an extraordinarily bad idea. You say this is your speciality; how did you acquire it? Are there any online courses, good books, or useful (i.e. non-bullshit) certifications that you can recommend?
- smu 15y ago
  It has become a lot easier to "learn by doing" without breaking any rules. If you are looking at web application security, there are a number of "simulation" games. The first that come to mind are Damn Vulnerable Web App (http://www.dvwa.co.uk/ http://www.dvwa.co.uk/), The Hackme Bank (http://www.mcafee.com/us/downloads/free-tools/hacme-bank.aspx http://www.mcafee.com/us/downloads/free-tools/hacme-bank.asp...) or OWASPs WebGoat (https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project https://www.owasp.org/index.php/Category:OWASP_WebGoat_Proje...) DVWA is probably the best choice for somebody with no prior knowledge. A quick google search on "dvwa walkthrough" will get you started.

FuzzyDunlop 15y ago

I think it'd be interesting to highlight some vaguely security-related measures that might make it less simple for attackers to shut down your site just by using it normally. I'm not so sure it's relevant to the SO question, mind, as it's more in line with optimisation than anything. This might include: * Using a caching layer to store and re-use the results of complex, infrequently changing queries, instead of querying the database on every request. * Using a message queue to handle the processing of certain things in the background. If you have an upload form that then manipulates or processes the file in some non-trivial manner, add it to the queue. The queue can drop messages or jobs if it gets too big. I only say this having developed some projects where holding the refresh key down for a few seconds on pages with lots of queries (along with the hundreds Drupal makes anyway) could crash MySQL. As could using a separate form that sent emails and processed images on-the-fly. Best not to present attackers prime opportunities to DOS your site.

napolux 15y ago
Interesting! :)

tptacek 15y ago

I am wary of software security advice that leads with "don't trust user input", or revolves around "validate user input". That principle has been the core of software security strategy for going on 20 years, and has bought us very little. In the real world, we have to start by acknowledging that the verb "trust" is situational, and that in some circumstances virtually all user input is "trusted" somehow. You could phrase this less tactfully as "Validate user input? No shit? Now what?" Here's some software security advice I'd like to offer, as a software security practitioner to the startup stars and the Dr. Drew Pinsky of HN (ducks): * Plan to update your platform software at inconvenient times. Dry-run your update process, so you know it will work on no notice. I personally believe you should also avoid your OS's packaged versions of things like Apache and nginx; having a known-working source build gives you control of when and how you'll apply patches; it's something you should be able to do easily. * Put someone on your team in charge of tracking your dependencies (C libraries, Ruby gems, Python easy_install thingies) and have a process by which you periodically check to make sure you're capturing upstream security fixes. You should run your service aware of the fact that major vulnerabilities in third-party library code are often fixed without fanfare or advisories; when maintainers don't know exactly who's affected how, the whole announcement might happen in a git commit. * Use TLS to encrypt data in motion and use GPG to encrypt data at rest, and don't do any other kind of crypto. GPG blobs are large and expensive looking, but getting custom crypto right is also very expensive. * Stay on your platform's "golden path" for web security issues. Rails developers should default-whitelist ActiveRecord models, enable CSRF protection, and avoid "html_safe-ing" strings so that the maximum amount of code inherits default protections against mass assignment, XSS, and CSRF. Anything you customize will probably bite you in the ass. Keep your code boring. * Triple check any piece of code that "shells out" to command line tools. By "triple check": have a process by which three signoffs are required to merge any such code into the deployment branch. * Be extraordinarily wary of library code for web apps that includes "native" C/C++ code. Very popular C library code for modern web platforms has been found susceptible to basic memory corruption issues, because the kinds of people that look for memory corruption bugs don't usually think to troll Github for Ruby, Python, and PHP code with native backend code; terrible bugs can thus stay latent for years in code you can point a URL to and read. * People will hate me for saying this but I'm here to offer honest advice: prefer almost any modern language to PHP or Perl. I don't know what to tell you other than that PHP and Perl apps fare worse on security assessments than everything else. * I have more than once recommended that people who are very very concerned about platform security (ie, about the likelihood that there are memory corruption bugs in their language stack) use JVM languages. * Do your admin stuff out-of-band. Write a separate admin app (bonus: the admin app can look shitty, and so is less expensive to maintain) that requires a VPN connection to access. Avoid special-privilege accounts in your normal apps. From years and years of experience working with startups: this is something you will mess up on. * Triple-check code that handles direct file uploads and downloads. The filesystem introduces a new namespace, so upload/download code needs to juggle different privilege and authorization domains to handle it. We see fewer problems at companies that dump blobs with opaque names into S3 than we do with apps that have a file repository with named files. * HAVE A SECURITY PAGE FOR YOUR APP. Have that page very cordially invite people to submit security flaws to an email address at your site; provide a PGP key for it. If I was maintaining a commercial app, I'd put a phone number on that page too. If you don't have this page, you should know that you are tacitly inviting people to report security flaws to Twitter.