Live data from Hacker News

Securing Your Site Like It’s 1999

24ways.org

11–20 of 33 posts

Re: Securing Your Site Like It’s 1999

#11

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.

You can reduce this to:

When I interview developers, I generally ask some basic questions about ____ - "Explain to me what _____ is?", or "How would you _____?"

Basic stuff, which - to my mind - literally every person who develops anything which is on _____ should know.

And a surprising number of people - even "senior" developers can't answer this stuff. It's really worrying.

Re: Securing Your Site Like It’s 1999

#12

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.

I have almost succeeded Stripe CTF 2 (runed out of time on final step because of the crowd). I am sure I can not give clear definition during an interview without a good refresh before.

Re: Securing Your Site Like It’s 1999

#13

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.

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.

Re: Securing Your Site Like It’s 1999

#14
post #4

The article mentions creating a clear access control policy. I haven’t worked on access control at all, but I’ve witnessed colleagues at multiple companies implementing it, something which I’ve only seen being done by hand. This obviously leads to bugs and security issues. I always wondered whether there wasn’t already software built solely or partly for the purpose of access control. I’ve recently been reading about…

There's Shibbeloth: https://www.shibboleth.net/ Not as easy as LDAP, it's designed for bigger places, like Universities

And there's Shibboleet too.

https://www.xkcd.com/806/

Re: Securing Your Site Like It’s 1999

#15
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…

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

Re: Securing Your Site Like It’s 1999

#16
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 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).

Re: Securing Your Site Like It’s 1999

#17

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.

I did a code review a while back with a new Web/Software Engineer II hire (I was not involved in the interview process) and noticed they were doing an HTTP GET request when they should have been doing a POST (attempting to change some values in the backend/database).

I talked to him about the issue, just chatting about GET, POST, PUT, etc...and all I got back was a deer-in-the-headlights look. He responded "I...I don't know what any of that is."

:(

I now ask "Can you explain what are some differences between an HTTP GET versus POST request?" with every web developer interview I do. If they get that one wrong or cannot answer...I don't bother with anything deeper.

Re: Securing Your Site Like It’s 1999

#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"?

Re: Securing Your Site Like It’s 1999

#19
> The first check you can make is to verify that a request’s origin and referer headers match the location of the website. These headers can’t be programmatically set

Can I stop reading right here? The referer header is presumably the oftenest spoofed header on the planet.

Re: Securing Your Site Like It’s 1999

#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 some great usability conveniences, such as numerical fields (think credit cards, age, dates…) in which the user could type all sorts of junk or poor formatting, and yet get some sane validation.

Nearly 20 years later, we're still a step backwards in having what I call "Forgiving UX", and have things like rigid drop-downs to select month/year of expiration on a credit card, instead of just lifting the first 4 digits—regardless of how the user typed them—and calling it a day.

https://perldoc.perl.org/perlsec.html#Taint-mode

Post reply on HN