[ad]
CORE GRASP for PHP is a web-application protection software aimed at detecting and blocking injection vulnerabilities and privacy violations.
As mentioned during its presentation at Black Hat USA 2007, GRASP is being released as open source under the Apache 2.0 license.
The present implementation protects PHP 5.2.3 against SQL-injection attacks for the MySQL engine, it can be installed with almost the same effort as the PHP engine, both in Unix and Windows systems, and protection is immediate with any PHP web application running in the protected server.
CORE GRASP works by enhancing the PHP execution engine (VM) to permit byte-level taint tracking and analysis for all the user-controlled or otherwise untrustable variables of the web application. Tainted bytes are then tracked and their taint marks propagated throughout the web application’s runtime.
Whenever the web application tries to interact with an DB backend using SQL statements that contain tainted bytes, GRASP analyzes the statment and detects and prevents attacks or abnormal
actions.
CORE GRASP was developed by CoreLabs, the research unit of Core Security Technologies. At CoreLabs, we plan to improve the tool and include new protections shortly. However, the invitation to collaborate with the project is open. If you would like to collaborate, please go to the GRASP website and subscribe to the mailing list.
The documentation for CORE GRASP is available here and you can download it here:
Or you can read more here.
fak3r says
This is very cool, and sounds like a lighter weight solution than mod_security, which was really slowing down my PHP apps due to all of its rules. Grasp’s FAQ doesn’t compare the two, but much of the functionality sounds the same, plus they recommend running Grasp alongside Suhosin, which I already run. I’m going to give this a go then, the only thing I don’t like is that you have to manually patch the PHP source code, then build it, then install it. While I would like to spend more time with my server, I just can’t, and apt-get and Debian keep things so easy on the keeping things up to date front; something manually patching and building would break.
Regardless, this, or at the very least Suhosin (Note: it’s on by default in OpenBSD’s PHP install, so that should tell you something) should be running on PHPs everywhere. While this seems alpha-y, I trust Suhosin with Prod work…I think this will join it soon too.
Ofer Shezaf says
fak3r,
mod_security provides a lot more coverage than GRASP which focuses on SQL injection and currently supports only mysql. It might be extended in the future for additional injection vulnerabilities, but does not provide full coverage for application security issues. Also keep in mind that mod_security is a swiss army knife enabling many differnt things and the actual protection stems from the rule set you use.
As to your performance issues: what rules are you using for ModSecurity? the popular gotroot rules are way to big an inefficient, but on the other hand offer you alot the GRASP does not do provide you, such as blacklists.
You may also want to look into the Core Rule Set (http://www.modsecurity.org/projects/rules), which is a much more optimized rule set.
Ofer Shezaf
ModSecurity Core Rule set project manager
dre says
i would say that mod_security would solve most of these problems, but if you want to get even closer to the application – you might want to look at fortifysoftware defender or imperva securesphere web application firewall (or whatever happened to the determina memory firewall after vmware killed all their products).
most of the appliance based web application firewalls are total crap. a few open-source projects are out there besides mod_security and core grasp – such as aqtronix webknight, dotnetids, which is based on php-ids and mod_anti_tamper, just to name a few
dre says
hot off the press: someone on the webappsec mailing-list also posted a link to jwall.org which adds a few java tools to mod_security.
the secure java framework at hdiv.org remains one of my current favorites (especially its support of struts2 and spring), especially along with the cookie revolver security framework
a bit dated, but the web security gateway project is also very interesting
Sandeep Nain says
@dre: no doubts web application firewall such as defender by fortify is a great product but expensive too…
and i find mod_security, a better option as it provides more flexibility… and yes being open source.. it is much cheaper too
Ofer Shezaf says
I might be biased but mod_security is probably a stronger and more flexible WAF than either. Just compare the rules language. And as said, for a fraction of the price (if zero can be labeled a fraction).
It does not have the GUI and buzz of the others, but if you are a hard core technologist who loves configuration files, you will find nothing better.
And if commercial products are already mentioned, we at Breach Security (www.breach.com) sell a commercial WAF based on mod_security with all the GUI and whistles you want. And still for far less.
dre says
when you’re a financial institution already paying $200k for every 100 developers to use fortifysoftware sca… and you’re still losing $30M a year or more due to internet-related fraud… i’m not sure that cost matters much when fortify will likely let you try defender for free until its optimally working. surely you understand that defender has applications hooks that mod_security can’t compete with. i would say the same is true for imperva.
for mom and pop or everyday websites – sure – mod_security is free and fine to use
dre says
another nice feature of commercial web application firewalls is support for web application security scanners to create rules for the vulnerabilities it finds directly to the waf’s. i suppose that mod_security / breach count – but smaller projects like grasp might not get included…
personally, i like the web application security scanner feature that submits findings as bugs to the development team’s issue tracking system.
Sandeep Nain says
I must say that modSecurity is the best WAF i have come across so far and that is because of the flexibility and powerful realtime traffic monitoring and analysis it provides.
it will also give excellent results on big commercial web applications if implemented correctly and not just everyday websites.
fak3r says
@Ofer Shezaf
As to your performance issues: what rules are you using for ModSecurity? the popular gotroot rules are way to big an inefficient, but on the other hand offer you alot the GRASP does not do provide you, such as blacklists.
You must have been watching over my shoulder, this is exactly the problem. I will try again with the core rules only next.
So, is there any way to get mod_security to work with Lighttpd?
Thanks Ofer!
dre says
@fak3r: there are multiple ways of running mod_security – the only way it wouldn’t work with lighttpd is the apache loaded module that only works with a local installation of apache.
probably the most common way deployed in your scenario (without apache) is in reverse-proxy mode
fak3r says
@Dre
Thanks for the advice, I’ve moved to Lighty from Apache 2.x on Debian recently, and I run Varnish for a reverse proxy/http accelerator. Can you tell me how you’d run mod_security in this setup? Would Varnish intercept php requests and run them through mod_sec or would Lighty use it directly? If it’s easier and you want to help more my email is my username at my username dot com
Thanks!
fak3r.
fazed says
@Ofer Shezaf
mod_security is actually very poor
at security a system, although alot
of sys admins rely on it there are many
bypass’s to get around its restrictions.
for example an attacker could base64 encode
their GET vars and pass them to a script he
has placed on the server which decodes it
and mod_security does not detect it.
it does mean that the attacker must
first have that file on the webserver
some how but after this the rest is
easy to bypass (such as base path restrictions)
dre says
@fak3r: read the last link i provided to “web security gateway” or just go to the mod_security website.
there’s also tons of other resources such as http://www.apachesecurity.net, this PDF on APIDS with ModSecurity by Ivan Ristic. Ryan Barnett also wrote a great book that covered mod_security well, Preventing Web Attacks with Apache, which included some custom mod_security rules as well as linked to the now popular gotroot rulset.
dre says
@fazed: hence why i was recommending fortifysoftware defender or imperva securesphere over mod_security – they go a little further by hooking into your application.
of course, no WAF will ever stop many complex business logic flaws, session management issues – e.g. CSRF
Ofer Shezaf says
@dre: Fortify hooks to the application. SecureSphere does not.
Ofer Shezaf says
@fazed: while I would be the 1st to tell you that no security solution, including a WAF is perfect, I think that your example is not relevant.
First, if this is the risk you forecast in your application, you can easily write a rule to prevent it – just detect base64 (detecting long strings without spaces would do the work). Saying that, avoiding use of HTTP as a hidden channel between two points controlled by the bad guys is very very difficult.
The strength of ModSecurity is that it can do whatever you want it to. The Core Rule Set, which is one example of such a use, does provide a pretty good solution for the problems it tries to address within its design limitations, namely: minimum false positives and minimal configuration.