Securing Your Site Like It’s 1999 • Hacker News Board

Re: Securing Your Site Like It’s 1999

#31

Post by Cpoll » Wed, Dec 12, 2018, 8:28 PM UTC

interfixus wrote: post #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.

This isn't to defend against a malicious user crafting requests, it's to defend against a malicious site tricking the user's browser into making an authenticated request. Said malicious site can't set those headers.

Edit: I think I misread your comment and you're not arguing that checking origin/referrer isn't enough for security, but rather that it will block legitimate, privacy-conscious users.

Using a CSRF token is a valid alternative, and it's mentioned just below in the article.

Re: Securing Your Site Like It’s 1999

#32

Post by Piskvorrr » Wed, Dec 12, 2018, 8:40 PM UTC

smush wrote: post #30

Piskvorrr wrote: post #16

Earlier quoted context omitted.

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…

Yeah, that makes sense. In other words, software is far easier to build, but requires much more effort to maintain - in which security is prominent.

Re: Securing Your Site Like It’s 1999

#33

Post by eftychis » Thu, Dec 13, 2018, 12:21 AM UTC

jandrese wrote: post #29

athenot wrote: 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 i…

Agree, it seems this is one area that inventing your own solution is tempting, yet people fail to realize the variety of cases that need to be supported and welded together. Same thing goes for IPs etc