From: Nick Kew Date: Tue, 22 Apr 2008 01:07:42 +0000 (+0000) Subject: Document DBD taint checking and its necessity. X-Git-Tag: 2.3.0~686 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=663c9d24d83fd36f0789fbd088315e90b12eb6f9;p=apache Document DBD taint checking and its necessity. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@650339 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_dbd.xml b/docs/manual/mod/mod_dbd.xml index 266b0fcbb7..ae20019abc 100644 --- a/docs/manual/mod/mod_dbd.xml +++ b/docs/manual/mod/mod_dbd.xml @@ -114,6 +114,38 @@ APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const c or to provide their own directives and use ap_dbd_prepare.

+
+SECURITY WARNING +

Any web/database application needs to secure itself against SQL + injection attacks. In most cases, Apache DBD is safe, because + applications use prepared statements, and untrusted inputs are + only ever used as data. Of course, if you use it via third-party + modules, you should ascertain what precautions they may require.

+

However, the FreeTDS driver is inherently + unsafe. The underlying library doesn't support + prepared statements, so the driver emulates them, and the + untrusted input is merged into the SQL statement.

+

It can be made safe by untainting all inputs: + a process inspired by Perl's taint checking. Each input + is matched against a regexp, and only the match is used. + To use this, the untainting regexps must be included in the + prepared statements configured. The regexp follows immediately + after the % in the prepared statement, and is enclosed in + curly brackets {}. For example, if your application expects + alphanumeric input, you can use:

+ + "SELECT foo FROM bar WHERE input = %s" + +

with other drivers, and suffer nothing worse than a failed query. + But with FreeTDS you'd need:

+ + "SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s" + +

Now anything that doesn't match the regexp's $1 match is + discarded, so the statement is safe.

+

An alternative to this may be the third-party ODBC driver, + which offers the security of genuine prepared statements.

+
DBDriver Specify an SQL driver