Hacker News new | past | comments | ask | show | jobs | submit
semi-extrinsic | on: A thousand fewer paths to root
I don't think this is true in general. If you deploy a good ole web application with sufficiently locked down inputs and thorough input validation, the AI will not succeed. The security engineering of 10 years ago still works in this regard. But it requires discipline to build small, minimalist, well engineered software that you as a human actually understand.
reassess_blind | parent | next
And then your language has a gaping hole (PHP or NodeJS), or the box you're running on has a gaping hole (Linux), or the PaaS you use has a gaping hole (Railway). There are just too many layers underneath the good ol' web application to claim that AI won't succeed.

Honestly, at this point the best we have is to hope the whitehat AI scanning for issues is stronger than the blackhat AI.

locknitpicker | root | parent
> There are just too many layers underneath the good ol' web application to claim that AI won't succeed.

I think you got it backwards. For your AI to succeed, it needs to poke a hole on all layers, not one in many layers. If an attacker pokes a hole in n-1 layers but the 1 layer remains untouched, the system's integrity is preserved.

Why do you think defense in depth is a basic concept?

tsimionescu | root | parent
Not really, no. If you're running an application server, then your entire app can get compromised if there's a security exploit in any of your app code, your web server, your kernel, your hypervisor.

Defense in depth says that simply compromising your application code shouldn't provide access to the physical hardware you're running on, and that's hopefully the case, but it doesn't mean your app is not hacked. It just hopefully means that a hack on your app code doesn't automatically give the attacker access to your entire company.

locknitpicker | root | parent
> Not really, no. If you're running an application server, then your entire app can get compromised if there's a security exploit in any of your app code, your web server, your kernel, your hypervisor.

That's really not how it works. You reach the compromise part if all layers are compromised. You don't reach the inner layers if you can't go past an outer layer. You're saying that if there is only one layer that is compromised, or all layers are compromised, your app can be compromised. But you're leaving out when you can't go through every single layer. That's the whole premise of defense in depth.

throwawayffffas | parent | next
As the TCP bug that surfaced a couple of weeks ago, that is not true, you depend on the kernel, your application runtime, and many layers of dependencies.

Many bugs live in all those layers that may undermine your ability to lock down inputs and outputs.

imafraidnot | parent
And then PHP (name your lang/OS/platform of choice) comes along and pulls your sufficiently locked down app into the gutter.

This is more fundamental than better input checking. Your compute substrate itself is flawed. Intelligence and speed is indeed the only thing between “safe” and “completely open”.

I fully agree it’s a good idea to be minimal etc but I don’t see it being sufficient in the long run.