
Website Database Security (2018) - mestacey
https://int64software.com/blog/2018/11/21/hardening-website-security-part-3-website-database-security/
======
raesene9
For anyone interested in the history of SQL Injection, the generally accepted
first article talking about it was in 1998 from rain.forest.puppy
[http://phrack.org/issues/54/8.html#article](http://phrack.org/issues/54/8.html#article)

It's interesting that it's managed to persist as a serious issue for over 20
years now.

~~~
ahje
I've seen plenty of web sites running 10+ year-old code written by someone's
neigbor's kid with an ancient PHP handbook in hand. Luckily, deprecating the
mysql extension in PHP in favor of the mysqli extension has broken a _lot_ of
ancient code like that.

~~~
raesene9
Yeah PHP has been a rich source of SQLi issues in the past, but it can crop up
anywhere.

I've seen it most languages/database engines and even where an ORM is in play
(e.g. ActiveRecord in rails) you can get it with bugs in the ORM
implementations.

------
supakeen
I think it would've been nice if you had shown a UNION or OR 1='1 attack as
well. Many database drivers/packages will block multiple queries in a single
statement :)

~~~
tarabanga
How does that work? Any pointers (that you know are of high quality) would
also/instead be great too.

------
bradfields
This might be the first time I've ever read an article like this and thought
"I actually do all of this". Perhaps the "Senior" in front of my job title
isn't as undeserved as it can sometimes feel :)

------
crgwbr
It amazes me how many systems ( _cough_ Heroku) leave database access open to
the Internet. Is that actually acceptable in most people’s threat model?
There’s no way I’d let my team deploy something like that to production.

~~~
rietta
The risk is not completely unmitigated in that they generate random database,
user, and passwords automatically. These are not the 'appname' password your
security-clueless developer chose. The question is what is the risk that
PostgreSQL has an authentication bypass vulnerability. Compared to the risk
that your web app developers got authentication and authorization at the web
app layer wrong, this is very unlikely. And given such a web application
vector, your database behind the firewall is just as vulnerable to attack
through the web app.

~~~
koolba
> The question is what is the risk that PostgreSQL has an authentication
> bypass vulnerability.

Well there was the whole OpenSSL Heartbleed issue that would only be an issue
if the DB is network accessible: [https://blog.hagander.net/postgresql-and-
the-openssl-heartbl...](https://blog.hagander.net/postgresql-and-the-openssl-
heartbleed-vulnerability-219/)

> Compared to the risk that your web app developers got authentication and
> authorization at the web app layer wrong, this is very unlikely. And given
> such a web application vector, your database behind the firewall is just as
> vulnerable to attack through the web app.

More layers and defense in depth is always a win for security. If nothing
else, it limits your attack surface and gives you time to respond to an issue
in one your layers.

~~~
rietta
Oh I agree on the layers. I'm all about the defense in depth.

------
snomad
If author stops by: good article, wish you covered application accounts. e.g.
some places create a unique app account per sub-domain, others do it via
application.

~~~
mestacey
That's a really good idea. I may write a another article or an addendum on it
in the future.

Thanks :)

