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

What should every programmer know about security?

stackoverflow.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: What should every programmer know about security?

#21

Post by rudhir-secpanel »

trafficlight wrote: post #4
kirinan wrote: post #3

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 th…

BackTrack is pretty overwhelming at the beginning. Do you have any suggestions on what programs/attacks will give you the most bang-for-your-buck?

Backtrack is used to install/host metasploit. If you find Metasploit daunting then you could use Armitage - a gui interface for metasploit.

Re: What should every programmer know about security?

#22

Post by smu »

kibwen wrote: post #5
kirinan wrote: post #3

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 th…

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?

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/), The Hackme Bank (http://www.mcafee.com/us/downloads/free-tools/hacme-bank.asp...) or OWASPs WebGoat (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.

Re: What should every programmer know about security?

#23

Post by bgilroy26 »

tptacek wrote: post #15

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 ph…

>People will hate me for saying this...

Here comes the first pitchfork-bearer! Are there ready examples of what makes the usage of Perl a security liability?

By grouping PHP and Perl together, it seems like the security issue you're highlighting is websites made by inexperienced programmers. Perl is much worse than PHP in this regard owing to the fact that Perl's history of being used by people building their first website goes back further than PHP's does.

The last time that I recall Perl being in the news for security was in the first quarter of this year when they were patching up the DDoS vulnerability in Ruby and Python [1] whereas Perl and CRuby had addressed the vulnerability in question in 2004.

I would argue that at least since 2007 or 2008, that the Perl programming demographics have shifted significantly and that most restauranteurs and florists who are trying their hand at making a page for their SMB are using PHP. At this point I would venture that the fat part of the bell curve of the Perl web programming population would be systems administrators who venture outside the bounds of their automation scripting domain.

Given the stereotypical sysadmin, I would posit that they might tend to spend extra time and energy on security (in building some script-y spaghetti monstrosity).

1. http://arstechnica.com/business/news/2011/12/huge-portions-o...

Re: What should every programmer know about security?

#24

Post by daeken »

bgilroy26 wrote: post #23
tptacek wrote: post #15

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 ph…

>People will hate me for saying this... Here comes the first pitchfork-bearer! Are there ready examples of what makes the usage of Perl a security liability? By grouping PHP and Perl together, it seems like the security issue you're highlighting is websites made by inexperienced programmers. Perl is much worse than PHP in this regard owing to the fact that Perl's history of being used by people building their first w…

> Are there ready examples of what makes the usage of Perl a security liability?

The `open` function used on untrusted input allows arbitrary code execution (I've gotten privilege execution via setuid perl scripts many times this way, as well as getting a shell on the box via web apps allowing this).

While there are many other common things I saw in real world apps, e.g. perl scripts using backticks for command execution and allowing me to run anything I wanted, the `open` one is by far the worst. It's insanely pervasive and incredibly easy to do.

Re: What should every programmer know about security?

#25

Post by jbp »

tptacek wrote: post #17
elorant wrote: post #14

Earlier quoted context omitted.

Here are a couple of great books about web/software security: http://www.amazon.com/The-Web-Application-Hackers-Handbook/d... http://www.amazon.com/Deadly-Sins-Software-Security-One-off/...

I love WAHH. I can't stand "Deadly Sins". I'd replace it with _The Tangled Web_, Zalewski's new web security book; WAHH and _Tangled_ is a formidable amount of knowledge to keep on tap.

If don't want/unable to get, Tangled Web, similar useful information by same author at "Browser Security Handbook" http://code.google.com/p/browsersec/wiki/Main

Re: What should every programmer know about security?

#26

Post by kirinan »

ww520 wrote: post #10
kirinan wrote: post #3

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 th…

I don't quite understand number 3? Can you elaborate number 3 a bit? How is that being used? Can SSL do the same thing? Or do you mean preventing CSRF kind of attack?

My previous reply was bad, and for that I apologize. Yes, use application keys for your services/controller to make sure that it indeed an app. This prevents session spoofing and CSRF. Rails does this automatically, so do a lot of other frameworks/languages so it isnt a big deal, but some people use services built on Scala or another language without frameworks, so they tend to be susceptible.

Re: What should every programmer know about security?

#27

Post by gbog »

tptacek wrote: post #15

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 ph…

The "stay on the golden path" rule is unrealistic except in corporate Java environments. It will conflict with other more important focus points than security: disruption, be faster than competition, do things thee hard way, etc. (All things well described in pg's essays).

I would require all devs to read OWASP and make sure they understand the core, then they can tweak in, hopefully knowing what they do.

Re: What should every programmer know about security?

#28

Post by spydum »

kirinan wrote: post #8
trafficlight wrote: post #4

Earlier quoted context omitted.

BackTrack is pretty overwhelming at the beginning. Do you have any suggestions on what programs/attacks will give you the most bang-for-your-buck?

The ones I use the most are: Wireshark (to analyze traffic coming too and from my website), Metasploit (To make social engineering exploits to make sure my servers arent vulnerable), Mantra Security Framework, Cisco OCS Mass Scanner (For breaking Cisco Routers), SQL Inject, SQL Scanner (Both for finding injection errors). If you master these, you can do a lot of cool things with them. Wireshark is your best friend wh…

wireshark just fine when things are over ssl. all you need is the private key. you'd be floored at how lazy some people are with their private keys.

Re: What should every programmer know about security?

#29

Post by tedunangst »

tptacek wrote: post #15

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 ph…

"Use TLS to encrypt data in motion" It's also worth checking that whatever language/library you're using bothers to validate the cert (AND the hostname). Many (most even?) don't by default. You have to ask extra nice in order to get a secure connection that's actually secure.
Post reply on HN