4 ms·

What about security? Is there a safe enough way to still use it today ?

by lovelyviking 6y ago

Diederich 6y ago
Sure it can be used safely. Appropriately sanitize inputs, don't pass things through the shell, pretty typical stuff.
- throw_away 6y ago
  also, taint checking built into the language to enforce sanitization: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
  - throwaway823882 6y ago
    This feature is one of those things that proves that the technology industry is bullshit. There's an entire industry, probably worth hundreds of billions of dollars, built around trying to detect insecure code and force it to be less insecure. Meanwhile, this one old language that nobody uses has a single option you enable to be [more] secure by default. And I'll bet you a billion dollars the reason other languages don't have it is "the design doesn't look very clean".
- fallat 6y ago
  If anything no input interpretation should happen, everything should just go directly to the program, and the program should not be capable of file operations. stdin/stdout only.
midasuni 6y ago
Why wouldn’t it be safe? Many scripts I have are only available internally so don’t need to worry about people hacking them (unless they want to risk being fired to look at say syslog messages without having to ssh into the box). Perl -T helps ensure there’s no tainting of variables - you take the parameter that’s passed and regex pull out the matching pattern you need to use. If your variable is a match of ([\d]+) then it’s only going to have numbers in, and you can use it fairly safely
Stranger43 6y ago
yes, in fact the security model of Apache mod_cgi(especially with mod_userexec) will isolate scripts to an single user, which is also the level most modern reverse proxy based setups offer. The problem was that the newbies writing cgi scripts in 1993 generally did not have much experience with input sanitation and had very few libraries to lean on to do it for them.

What about security? Is there a safe enough way to still use it today ?

Diederich 6y ago

Sure it can be used safely. Appropriately sanitize inputs, don't pass things through the shell, pretty typical stuff.

throw_away 6y ago
also, taint checking built into the language to enforce sanitization: https://en.wikipedia.org/wiki/Taint_checking https://en.wikipedia.org/wiki/Taint_checking
- throwaway823882 6y ago
  This feature is one of those things that proves that the technology industry is bullshit. There's an entire industry, probably worth hundreds of billions of dollars, built around trying to detect insecure code and force it to be less insecure. Meanwhile, this one old language that nobody uses has a single option you enable to be [more] secure by default. And I'll bet you a billion dollars the reason other languages don't have it is "the design doesn't look very clean".
fallat 6y ago
If anything no input interpretation should happen, everything should just go directly to the program, and the program should not be capable of file operations. stdin/stdout only.

midasuni 6y ago

Why wouldn’t it be safe? Many scripts I have are only available internally so don’t need to worry about people hacking them (unless they want to risk being fired to look at say syslog messages without having to ssh into the box). Perl -T helps ensure there’s no tainting of variables - you take the parameter that’s passed and regex pull out the matching pattern you need to use. If your variable is a match of ([\d]+) then it’s only going to have numbers in, and you can use it fairly safely

Stranger43 6y ago

yes, in fact the security model of Apache mod_cgi(especially with mod_userexec) will isolate scripts to an single user, which is also the level most modern reverse proxy based setups offer. The problem was that the newbies writing cgi scripts in 1993 generally did not have much experience with input sanitation and had very few libraries to lean on to do it for them.