Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Taint checking

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Pmalmsten (talk | contribs) at 01:38, 12 May 2015 (Improved the grammar of a sentence). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Taint checking is a feature in some computer programming languages, such as Perl[1] and Ruby,[2] designed to increase security by preventing malicious users from executing commands on a host computer. Taint checks highlight specific security risks primarily associated with web sites which are attacked using techniques such as SQL injection or buffer overflow attack approaches.

The concept behind taint checking is that any variable that can be modified by an outside user (for example a variable set by a field in a web form) poses a potential security risk. If that variable is used in an expression that sets a second variable, that second variable is now also suspicious. The taint checking tool proceeds variable by variable until it has a complete list[citation needed] of all variables which are potentially influenced by outside input. If any of these variables is used to execute dangerous commands (such as direct commands to a SQL database or the host computer operating system), the taint checker warns that the program is using a potentially dangerous tainted variable. The computer programmer can then redesign the program to erect a safe wall around the dangerous input.

Taint checking may be viewed as a conservative approximation of the full verification of non-interference or the more general concept of secure information flow.[3] Because information flow in a system cannot be verified by examining a single execution trace of that system,[4] the results of taint analysis will necessarily reflect approximate information regarding the information flow characteristics of the system to which it is applied.[5]

Taint checking is a black-listing approach as it asserts that certain values are dangerous. The white-listing equivalent is trademarking.

Example

The following dangerous Perl code opens a large SQL injection vulnerability by not checking the value of the $name variable:

#!/usr/bin/perl
my $name = $cgi->param("name");  # Get the name from the browser
...
$dbh->TaintIn = 1;
$dbh->execute("SELECT * FROM users WHERE name = '$name';"); # Execute a SQL query

If taint checking is turned on, Perl would refuse to run the command and exit with an error message, because a tainted variable is being used in a SQL query. Without taint checking, a user could enter foo'; DROP TABLE users --, thereby running a command that deletes the entire database table. Much safer would be to encode the tainted value of $name to a SQL string literal and use the result in the SQL query, guaranteeing that no dangerous command embedded in $name will be evaluated. Another way to achieve that is to use a prepared statement to sanitize all variable input for a query.

One thing to note is that Perl DBI requires one to set the TaintIn attribute of a database handle as well as enabling taint mode to check one's SQL strings.

History

Perl supported tainting from at least 1989 as the -T switch[6] was included in Perl 3.[7]

In 1996 Netscape implemented data tainting in server-side JavaScript in Netscape Communications Server,[citation needed] as well as client-side for Netscape Navigator 3.[8] However, since the client-side support was considered experimental it shipped disabled (requiring user intervention to activate), and required page authors to modify scripts to benefit from it. Other browser vendors never implemented the functionality; nor did Communications Server's primary competition, Microsoft's (then) new Internet Information Server.

References

  1. ^ perlsec - Perl security. Perl 5 development team. 2012-05-20.
  2. ^ Programming Ruby --- The Pragmatic Programmer's Guide. Addison Wesley Longman. 2001. pp. 253 (Ch. 20).
  3. ^ A. Sabelfeld and A. C. Myers, "Language-based information-flow security", IEEE Journal on Selected Areas in Communications, 2003.
  4. ^ J. Ligatti, L. Bauer, D. Walker. "Edit automata: Enforcement mechanisms for run-time security policies". International Journal of Information Security, 2005
  5. ^ T. Terauchi and A. Aiken. "Secure information flow as a safety problem". In 12th International Static Analysis Symposium, September 2005.
  6. ^ Contact details. "perlsec". perldoc.perl.org. Retrieved 2012-05-29.
  7. ^ Perl in a Nutshell, Second Edition, Patwardhan, Siever and Spainhour, ISBN 0-596-00241-6
  8. ^ "JavaScript: The Definitive Guide". Docstore.mik.ua. Retrieved 2012-05-29. [...] the data-tainting security model is experimental in Navigator 3.0, and is not enabled by default. It is expected to be the default security model in version 4.0 of Navigator, however.