
Securing Your Site Like It’s 1999 - mooreds
https://24ways.org/2018/securing-your-site-like-its-1999/
======
jlangenauer
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.

~~~
mdpopescu
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 exec_sql with a
string from a stored procedure (had it happen at two different companies).

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

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

~~~
Piskvorrr
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).

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

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

------
0db532a0
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 LDAP. While I don’t have any experience using
it, I wondered whether you could simply use LDAP to implement your access
control. Someone on Stack Overflow asked the same question:
[https://stackoverflow.com/questions/3363267/ldap-for-
applica...](https://stackoverflow.com/questions/3363267/ldap-for-application-
access-control-how-much-should-it-control). The accepted answer mentions that
LDAP can be used for high-level access information, but that the lower level
should be handled by the application, as the LDAP scheme would otherwise
become complicated. Fair enough.

My question is: What experience do others here have with implementing access
control? Have you used LDAP? Is there another general tool built for this
purpose which saves us the trouble of building our own system? Surely someone
like IBM and Microsoft have built something for this. Are there any open
source alternatives?

~~~
blakesterz
There's Shibbeloth: [https://www.shibboleth.net/](https://www.shibboleth.net/)

Not as easy as LDAP, it's designed for bigger places, like Universities

~~~
chrisswanda
And there's Shibboleet too.

[https://www.xkcd.com/806/](https://www.xkcd.com/806/)

------
athenot
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](https://perldoc.perl.org/perlsec.html#Taint-mode)

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

~~~
eftychis
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

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

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

------
techbio
In a world of machine learning and massive breaches, "security by obscurity"
is ever further from appropriate in any case at all.

