User privileges for unsanatized code

Question

We all know there are still vulnerable code out there even though they may or may not get exploited and found for hacking attempts. I've seen people do it countless times and have a possibly plausible solution I've been working on for this. The only thing I lack is possibilities and opinions for this idea.

Based off of the Web Application Firewall, I planned on creating a vBulletin plugin (first) in order to detect unsanatized code by including functions for all possible unsanatized code and sandbox it. In order to lower privileges of anyone without a key (either user defined or generated), either the forum owner will manually access the control panel and disallow what code gets filtered/blocked or automatically detect what known vulnerabilities the code may have and give a 404 to any user that inputs arbitrary exploitable code such as SQLi (accessing a table other than the one on the page allows) and others.

Since people have told me that using a Web Application Firewall has many bypasses that are just annoying to the hacker, I was wondering whether or not sandboxing and lowering privileges is a good idea if I improve the functionality on vBulletin through numerous plugins/products so it can be at least 90% versatile over time?

Opinions are welcome as well. Another question is known bad coding practices. I don't know everything, but I know my mistakes and people have broken and hacked their way through my code to show me. What bad coding practices are known and uncommon/known and common in PHP/JS?

Thanks for the time. If this would fit in another SE site, sorry & many thanks if it gets migrated.

Edit

I was wondering whether or not protecting the additions to a site before protecting the site overall is a good idea. If we look at vBulletin as it stands right now, people are still creating plugins and products that aren't 100% secured and lead to finding that there may be unnecessary code, improper sanitation, and/or unsanatized input. This would wrap the code and protect it through privilege restrictions. The cons about this is less knowledge about security to the owner(s), but more time knowing your website is protected whether you're vulnerable or not.

Answer 1

whether or not sandboxing and lowering privileges is a good idea

ALWAYS!!! Every time, everywhere (English is weird), isolate your processes. In an ideal world, we'd SELinux the hell out of every application, user, file, etc.

A properly established mandatory access control provides both protection against exploits and detection of compromise when you see patterns in your audit logs that just shouldn't be there, which of course you're always reviewing to correct bad rules or notice something unwanted has happened.

WAF, MAC, firewalls, etc. are body armor for your web server. They make you heavier and slower, and chest armor doesn't stop you from being shot in the arm, but it does improve your survival odds.

AppArmor is a simpler interface to the Linux security modules, and a decent substitute for corralling specific applications that you consider high-risk if SELinux is melting your brain.

whether or not protecting the additions to a site before protecting the site overall is a good idea

Yes again! The more compartmentalized you can make things, the better off you are. If the a module only needs access to the posts table, provide it a context where it can't access the credential table, etc. It's a lot harder to leak the access you don't have than the access you do have.

Answer 2

There's good info in some of the other answers, for sure. I'd add that you can defeat almost all low-level code injections with a simple trick: use a non-x86 processor. Malware or payload written for x86 simply does not work on non-x86 processor. Linux and some BSD's have been ported to many processor architectures. If you use a portable web stack, then you can just compile it for those architectures and deploy a web application on top of it. Configure things correctly and now you just worry about application level attacks.

Some will accuse it of being security by obscurity. Not true. This is obfuscation and it has proven value. It works so long as it's not widely adopted to the point that hackers put a bunch of effort into the tactic. It's worked for me and many others, including huge NUMA/mainframe markets, for almost ten years. That's saying something. Most attackers use premade kits. And almost all people making kits write x86 desktop/server or ARM mobile. There's simply not a substantial labor force available to easily exploit your stuff running on POWER, Alpha, MIPS, SPARC, etc. So, it's kind of economics + obfuscation working to your advantage.

Remember, though, to combine this trick with good security practices in area of choice of software, configuration, permissions, monitoring, etc. Obfuscation alone isn't enough to prevent all issues. Just a bunch of them. ;)

Note: I'd also try to avoid using platforms that are easy to bypass or inject code into. PHP has a bad history with that kind of thing. The static, type safe, managed runtimes are usually the easiest to secure from problematic code. You just have less to worry about with them and we have tricks like SFI and Native Client for dealing with native code on those platforms if one is so inclined.