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

31–40 of 51 posts

Re: What should every programmer know about security?

#31

Post by rdl »

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…

This is a great list.

I'd add some of the relevant things from security strategy over the past 20 years, like "log lots of stuff".

There are many things which help availability (backups, easy deployment, tests, etc.) which also help security. If it's relatively easy to push an update, it's a lot more likely that you'll be able to rapidly respond to a vulnerability, or will have pre-emptively updated away from a vulnerability.

The most interesting things I've found recently have been in the "we can't touch that because we both don't understand it and because it's not working" parts of a complete site.

Re: What should every programmer know about security?

#32

Post by bgilroy26 »

daeken wrote: post #24
bgilroy26 wrote: post #23

Earlier quoted context omitted.

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

Those sound like two good leads, thank you!

Re: What should every programmer know about security?

#33

Post by DanielRibeiro »

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…

I'd also add: Remote timing attacks are practical[1, 2]. Twitter as target of it in the past[3].

[1] http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html

[2] http://codahale.com/a-lesson-in-timing-attacks/

[3] http://scforum.info/index.php?topic=4358.0

Re: What should every programmer know about security?

#34

Post by peteretep »

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 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.

If you're talking about copying and pasting formmail.php or .cgi from somewhere on the internet, sure. Beyond that, what exactly is the issue with Perl? Where are the security issues with Dancer? Catalyst? DBIx::Class?

Re: What should every programmer know about security?

#35

Post by peteretep »

daeken wrote: post #24
bgilroy26 wrote: post #23

Earlier quoted context omitted.

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

If your web application is opening and closing files based on user input, without checking them first, you have bigger issues. Blaming this on the language seems bizarre.

Re: What should every programmer know about security?

#37

Post by jkn »

peteretep wrote: post #35
daeken wrote: post #24

Earlier quoted context omitted.

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

If your web application is opening and closing files based on user input, without checking them first, you have bigger issues. Blaming this on the language seems bizarre.

True but perl makes it amazingly easy to exploit.

Suppose that you know the source contains this line:

  open(file_handler, "$userinput");
How much work and what assumptions do you need to exploit this? In perl it's that easy:

  $userinput = "cat /etc/passwd |zenity --text-info |";
  open(file_handler, "$userinput");

Re: What should every programmer know about security?

#38

Post by bgilroy26 »

jkn wrote: post #37
peteretep wrote: post #35

Earlier quoted context omitted.

If your web application is opening and closing files based on user input, without checking them first, you have bigger issues. Blaming this on the language seems bizarre.

True but perl makes it amazingly easy to exploit. Suppose that you know the source contains this line: open(file_handler, "$userinput"); How much work and what assumptions do you need to exploit this? In perl it's that easy: $userinput = "cat /etc/passwd |zenity --text-info |"; open(file_handler, "$userinput");

Do you usually try $UserInput $Userinput $userInput $user_input etc. when you do that?

It couldn't run your code if it had an uninitialized variable in it, right?

Re: What should every programmer know about security?

#39

Post by jkn »

bgilroy26 wrote: post #38
jkn wrote: post #37

Earlier quoted context omitted.

True but perl makes it amazingly easy to exploit. Suppose that you know the source contains this line: open(file_handler, "$userinput"); How much work and what assumptions do you need to exploit this? In perl it's that easy: $userinput = "cat /etc/passwd |zenity --text-info |"; open(file_handler, "$userinput");

Do you usually try $UserInput $Userinput $userInput $user_input etc. when you do that? It couldn't run your code if it had an uninitialized variable in it, right?

It's vulnerable because the user controls the content of $userinput, the variable name doesn't matter. Real code would look like this:

  #!/usr/bin/perl

  print "Enter filename: ";
  $filename = ;
  open(file_handler, "$filename");
If you see this code, you know that you can execute any command by giving it at the filename prompt and appending a '|' character. For example giving cat /etc/passwd |zenity --text-info | will popup a dialog with the content of /etc/passwd.

Re: What should every programmer know about security?

#40

Post by peteretep »

jkn wrote: post #37
peteretep wrote: post #35

Earlier quoted context omitted.

If your web application is opening and closing files based on user input, without checking them first, you have bigger issues. Blaming this on the language seems bizarre.

True but perl makes it amazingly easy to exploit. Suppose that you know the source contains this line: open(file_handler, "$userinput"); How much work and what assumptions do you need to exploit this? In perl it's that easy: $userinput = "cat /etc/passwd |zenity --text-info |"; open(file_handler, "$userinput");

> Suppose that you know the source contains this line

Then you have a massive damn problem, and you could set up the same strawman about almost any language - if you're starting from the premise that you are piping arbitrary user input to a system call unimpeded, all bets are off.

Shall we try some other examples? Let's say you accept input from a user, and dump it unchecked in to output shown to the user via Ruby. OH NOES! Ruby is insecure because it supports CSRF! Or, let's say you use Python and pass in input from a user unimpeded straight to the database without using the quoting mechanisms! OH NOES! Python is insecure because it enables SQL injections! etc etc etc

But wait! you say... Sensible programming languages have specific features to stop these kinds of attacks! And you're right. That's why Perl has taint mode... for when you're dumb enough to pass user input straight to open: http://perldoc.perl.org/perlsec.html#Taint-mode

Post reply on HN