Stefan Esser wrote: > Hi Dan, >> I believe the primary use case for taint mode would be to use it in >> development: taint mode is a mode which can be turned on to give you >> an idea of where your application may have exposed some >> vulnerabilities; let you fix those identified vulnerabilities; then >> turn off for production purposes. The speed of the implementation, if >> this is indeed the intention for taint mode, would therefore be >> irrelevant. > The problem here is that both approaches fail to be completely secure > even when your test environment > has 100% code coverage. And I am speaking of real 100% ... Currently > there is no tool that can > ensure that. All PHP CC tools I know of so far will for example not > handle the ternary operator correctly. > > The reason why both taint mode implementations fail are simple. Take the > following statement. > > $sql['id'] = mysql_real_escape_string($_GET['id']); > $query = "SELECT * FROM table WHERE id=".$sql['id']; > > Wietse's taint mode will consider this statement safe and never cry. > GRASP on the other hand will see that there is user supplied data in the > SQL query, but will ignore it > because it is a number. It will only react if $sql['id'] contains a > string. Atleast the very first version did > this. > > This means currently both approaches would tell the developer that they > are safe, while they are in fact not. > > Stefan Esser >
Hi all, I'm one of CORE GRASP's developers. GRASP was designed to be used in production stage and hence it is unacceptable to have false positive and false negative alarms. As GRASP's objective is to enhance protection in run-time it was only designed to block on-going attacks and not to warn the developer about insecure coding habits. We think that Venema's Taint mode is a lot more helpful in this task. Going back to Stefan's example: > $sql['id'] = mysql_real_escape_string($_GET['id']); > $query = "SELECT * FROM table WHERE id=".$sql['id'] It is true that GRASP won't raise an alarm unless $sql['id'] has non-numeric characters. This was a design decision since our description of an attack does not include this example. After analyzing this example, we cannot see how an attacker could perform a SQL-Injection attack only with numeric characters; that's why GRASP will not detect this as an attack. Ezequiel Gutesman -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
