Live data from Hacker News

Securing Your Site Like It’s 1999

24ways.org

21–30 of 33 posts

Re: Securing Your Site Like It’s 1999

#21
post #13

Earlier quoted context omitted.

I've been developing web apps since .NET 3, and the only thing I understand (and can claim to guard against [1]) in the OWASP top 10 is SQL injection. I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... which, given that Google itself seems to have problems with it, is quite difficult. [1] - claim, because you never know when someone happily calls exe…

> I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... No. Just no. Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in…

> Sell yourself as a software engineer who knows security, and watch the money rain as literally everyone tries to hire you

How can you brag about the fact that a software engineer who knows security is worth more on the market, then try to claim that every engineer needs to know how to write highly secure code? Those are incompatible ideas.

A lock manufacturer designs locks. A carpenter designs the building the lock is securing.

You wouldn't rely on your carpenter to build you a lock, because you understand that they are two separate domains of knowledge. You need to have this same mindset about good security and good engineering.

Digital security requires a high amount of specialized knowledge and involves far more variables than lock construction. It also requires constant vigilance and integration, where as a lock is fire-and-forget.

Re: Securing Your Site Like It’s 1999

#22
post #13

Earlier quoted context omitted.

> I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... No. Just no. Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in…

No they don't. Engineers building bridges don't sit around choosing what kind of fences or security cameras the construction site needs.

The might think about whether the bridge can cope with a hurricane, however.

Re: Securing Your Site Like It’s 1999

#23
post #13

Earlier quoted context omitted.

> I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... No. Just no. Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in…

No they don't. Engineers building bridges don't sit around choosing what kind of fences or security cameras the construction site needs.

they may not know the models of cameras and the specs, but they do know they need to attach them somewhere and how they work.

Re: Securing Your Site Like It’s 1999

#25
post #9

When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?" Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know. And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.

“What is the OWASP top 10?” I can forgive someone who can’t explain how XSS or CSRF works (I’m not sure I can explain it so clearly myself—kudos to the article’s author for the excellent explanation) if they know about the top 10 and have read it at least once.

Open Web Application Security Project (OWASP)

Last year: https://www.owasp.org/index.php/Top_10-2017_Top_10

Re: Securing Your Site Like It’s 1999

#26
post #21
post #13

Earlier quoted context omitted.

> I always try to explain to my clients that web security is a complex field and they should hire a pro for that area... No. Just no. Every other field of engineering includes security and safety as a core requirement of anything they do. Software engineering is no different, and while specialists can help, every engineer needs to know how to write secure code if we are to improve the sad situation the Internet is in…

> Sell yourself as a software engineer who knows security, and watch the money rain as literally everyone tries to hire you How can you brag about the fact that a software engineer who knows security is worth more on the market, then try to claim that every engineer needs to know how to write highly secure code? Those are incompatible ideas. A lock manufacturer designs locks. A carpenter designs the building the lock…

> How can you brag about the fact that a software engineer who knows security is worth more on the market, then try to claim that every engineer needs to know how to write highly secure code? Those are incompatible ideas.

Software developers who have the abilities they should are more valuable than those who . . . don't. That doesn't seem controversial.

Re: Securing Your Site Like It’s 1999

#27
post #18

When I interview developers, I generally ask some basic questions about security - "Explain to me what an XSS attack is?", or "How would you defend a web app against SQL injection?" Basic stuff, which - to my mind - literally every person who develops anything which is on the web should know. And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.

Do you expect a better answer for the second than "use a framework that parses the input in a way that escapes the input such that it's not interpreted as a command"?

Prepared statements tend to be the best answer for most cases which is similar to the approach you describe but is natively supported by most SQL dialects and also improves performance.

In my experience, many developers and even experienced security engineers can fail to give this answer though.

Re: Securing Your Site Like It’s 1999

#28
post #27
post #18

Earlier quoted context omitted.

Do you expect a better answer for the second than "use a framework that parses the input in a way that escapes the input such that it's not interpreted as a command"?

Prepared statements tend to be the best answer for most cases which is similar to the approach you describe but is natively supported by most SQL dialects and also improves performance. In my experience, many developers and even experienced security engineers can fail to give this answer though.

That's only relevant to know if you're actually implementing the piece that takes raw input and builds a query out of it, and most devs don't work with that piece on a day-to-day basis.

Knowing that you need to use a framework that takes care of input sanitizing is enough for the typical dev.

Edit: Expecting "prepared statements" as "the" answer seems close to making it a trivia question rather than "sufficient understand for doing the job" question.

Re: Securing Your Site Like It’s 1999

#29
post #20

It's worth mentioning that in 1999 there were already tools that helped. Perl's Taint Mode was one of them. In a nutshell, any variables containing user input could not be used for stuff involving OS paths, system calls or databases. The only way to use such input would be to "launder" the data, usually by using regular expressions to pull out the pieces that actually look plausible. As a side-effect, this introduced…

The thing that drives me crazy is when you have a form that tells you to enter the date, so you go MM/DD/YYYY and when you hit submit it comes back and tells you that it wants MM-DD-YYYY.

That's something the parser could just as easily do itself and avoid making more work for the user. Ideally you would use a parser that's smart enough to figure out 95% of the cases and do the right thing and only return errors if it's completely unparseable or ambiguous.

A date field should be able to accept all values like:

  2018-12-13

  12/13/2018

  Dec 13 18

  December 13, 2018

  12-13-平成三十年

  13.0.6.1.3

  1544677200
In cases where the input is ambiguous the parser can make its best guess and toss a warning. Preferably allowing the user to inspect its guess to see if is right.

Re: Securing Your Site Like It’s 1999

#30

Earlier quoted context omitted.

No they don't. Engineers building bridges don't sit around choosing what kind of fences or security cameras the construction site needs.

The abstraction doesn't fit. Where the civil engineers would be expected to build a bridge that doesn't collapse when the wind is Just Right (key word: Tacoma Narrows Bridge), software makers are expected to build a lock that doesn't open when someone whistles Just Right (key word: SQL injection).

Bridge builders are not expected to make the bridge itself defend against saboteurs, unlike software. To painfully extend the scenario: the wind is relatively well understood and once you've learned a lesson and guarded against it as a bridge builder, a given bridge can be considered stable.

Not so with software. One vuln fix, 5 more show up to take its place over time.

Malicious actors & botnets = the wind now (bear with me please). Once the bridge no longer collapsed via a certain Just Right tune, the wind would stop blowing the old Just Right way and instead try finding a new Just Right way, like whirling in a tight circular motion in just the right spot to see if it can unscrew bolts, or attempt -ddos- to tornado itself into a waterspout to try to collapose the bridge.

Security is not a one and done operation.

Post reply on HN