Untainting module for Apache

mod_taint is a new module to apply Perl-style taint checking
to untrusted data. It's a lot smaller and simpler than
mod_security, but offers a useful tool to protect a range
of applications.

It's now up-and-running and working well for me, and ready
for wider testing and feedback.

I've put the module together with documentation on my
apache.org space at:

http://people.apache.org/~niq/mod_taint.html
http://people.apache.org/~niq/mod_taint.c

Feedback welcome.

--
Nick Kew

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Untainting module for Apache

----- Nick Kew wrote:
> mod_taint is a new module to apply Perl-style taint checking
> to untrusted data. It's a lot smaller and simpler than
> mod_security, but offers a useful tool to protect a range
> of applications.
>=20
> It's now up-and-running and working well for me, and ready
> for wider testing and feedback.
>=20
> I've put the module together with documentation on my
> apache.org space at:

Why not put it in svn in httpd's sandbox?

> http://people.apache.org/~niq/mod_taint.html
> http://people.apache.org/~niq/mod_taint.c

does it make more sense to use it on a reverse proxy or
on the backend in question?

> Feedback welcome.
>=20
> --=20
> Nick Kew
>=20
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project=
..
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>=20
--=20
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Untainting module for Apache

On 30 Sep 2010, at 18:23, Igor Galić wrote:

> Why not put it in svn in httpd's sandbox?

Hadn't 100% decided ...

>> http://people.apache.org/~niq/mod_taint.html
>> http://people.apache.org/~niq/mod_taint.c
>=20
> does it make more sense to use it on a reverse proxy or
> on the backend in question?

Either of those might find a use for it. Running it on a proxy
has the advantage of being the first port of call, so long
as nothing bad can come from behind the proxy. I guess
that's a similar question to authentication at the proxy.
The "what are you protecting against" (malicious vs
accidental attack) might be relevant too if you have
both internal/trusted and external/untrusted users.

--=20
Nick Kew


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Untainting module for Apache

Nick Kew wrote:
> ~snip~

> Either of those might find a use for it. Running it on a proxy
> has the advantage of being the first port of call, so long
> as nothing bad can come from behind the proxy. I guess
> that's a similar question to authentication at the proxy.
> The "what are you protecting against" (malicious vs
> accidental attack) might be relevant too if you have
> both internal/trusted and external/untrusted users.
>

I'll have to look for the reference articles, but a quick summary of them:
Majority of recent corporate security breaches have been insider jobs.
disgruntled employees, recently dismissed, or not thinking were the
usual causes.
I know it was a Gartner and Associates report. [ for whatever the source
is worth ]

So a best practice for securing is there is no trusted user. makes for a
not very usable system though.
I could easily see mod_taint giving a more usable system without losing
a lot in the security of the system.

Jaqui


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Untainting module for Apache

J. Greenlees wrote:
> Nick Kew wrote:
>> ~snip~
>
>> Either of those might find a use for it. Running it on a proxy
>> has the advantage of being the first port of call, so long
>> as nothing bad can come from behind the proxy. I guess
>> that's a similar question to authentication at the proxy.
>> The "what are you protecting against" (malicious vs
>> accidental attack) might be relevant too if you have
>> both internal/trusted and external/untrusted users.
>>
>
> I'll have to look for the reference articles, but a quick summary of
> them:
> Majority of recent corporate security breaches have been insider jobs.
> disgruntled employees, recently dismissed, or not thinking were the
> usual causes.
> I know it was a Gartner and Associates report. [ for whatever the
> source is worth ]
>
> So a best practice for securing is there is no trusted user. makes for
> a not very usable system though.
> I could easily see mod_taint giving a more usable system without
> losing a lot in the security of the system.
>
> Jaqui

oops, I was wrong, it was the U.S. Secret Service report.
http://www.secretservice.gov/ntac_its.shtml


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org