Daniel Fdez. Bleda | 7 Jul 20:45 2006

Contributed patch adding crypto features [Forrester evaluation of web application firewalls] Documentation

Here's the doxygen documentation.
I attach it in RAR format due limitations in the mailing list.

-- 
_________________________________
Daniel Fernández Bleda
Gerente de cuentas
Consultor en Seguridad
CISA, CISSP, ISO27001 Lead Auditor
OPSA/OPST Trainer, CHFI Instructor
dfernandez <at> isecauditors.com

Internet Security Auditors, S.L.
c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona
Tel: 93 305 13 18
Fax: 93 278 22 48
www.isecauditors.com
          ____________________________________
Este mensaje y los documentos que, en su caso lleve anexos, pueden
contener información confidencial. Por ello, se informa a quien lo
reciba por error que la información contenida en el mismo es reservada
y su uso no autorizado está prohibido legalmente, por lo que en tal
caso le rogamos que nos lo comunique por la misma vía o por teléfono
(93 305 13 18), se abstenga de realizar copias del mensaje o remitirlo
o entregarlo a otra persona y proceda a borrarlo de inmediato.

En cumplimiento de la Ley Orgánica 15/1999 de 13 de diciembre de
protección de datos de carácter personal, Internet Security Auditors
S.L., le informa de que sus datos personales se han incluido en
(Continue reading)

Daniel Fdez. Bleda | 7 Jul 20:32 2006

Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

Ryan,

As Ivan explained, those functionalities refer to the use of
cryptography to avoid URL alteration, resource guessing,
cookie alteration, etc.

We at Internet Security Auditors have been using for some time
ModSecurity.

It has proven to be a great tool. From our experience in security
assessment, we've found some areas concerning web application security
that lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it by
extending it to suit our needs to provide better services to our
customers.

We have been working on that for some months and now (missing deep
performance and security testing which are next items in our agenda),
we'd like to advance some code to make this functionalities available
to ModSecurity 1.9.X. users.

This code is a proof of concept almost functional. As I've already
said, it has not been fully tested. Our intention is that ModSecurity
users do a some beta testing and report problems that eventually will
emerge (as is being done with ModSecurity itself).

We're glade to contribute some new features to ModSecurity community
hoping they may be useful to anyone who may be willing to add strong
cryptography protection to their web applications.

(Continue reading)

Ryan Barnett | 7 Jul 21:13 2006
Picon

Re: Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

Thanks for the info.  I had seen some presentation info (PPT or PDF) for a talk that I think you gave on this subject awhile ago, but there was no code available.  I will certainly try this out.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 7/7/06, Daniel Fdez. Bleda <dfernandez <at> isecauditors.com> wrote:
Ryan,

As Ivan explained, those functionalities refer to the use of
cryptography to avoid URL alteration, resource guessing,
cookie alteration, etc.

We at Internet Security Auditors have been using for some time
ModSecurity.

It has proven to be a great tool. From our experience in security
assessment, we've found some areas concerning web application security
that lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it by
extending it to suit our needs to provide better services to our
customers.

We have been working on that for some months and now (missing deep
performance and security testing which are next items in our agenda),
we'd like to advance some code to make this functionalities available
to ModSecurity 1.9.X. users.

This code is a proof of concept almost functional. As I've already
said, it has not been fully tested. Our intention is that ModSecurity
users do a some beta testing and report problems that eventually will
emerge (as is being done with ModSecurity itself).

We're glade to contribute some new features to ModSecurity community
hoping they may be useful to anyone who may be willing to add strong
cryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, but
not to disturb normal list usage, if you anyone is planning to submit
error logs or patches, you can contact us at support at isecauditors.com).

We expect, after a deep review and acceptance from Ivan Ristik, this
functionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancing
ModSecurity to be able to apply cryptography to its web application
firewall tasks.

This effort has been deployed covering two areas:

   - Cookie protection:

   Functionalities have been added to protect web applications that
   use cookies as state management mechanism against cookie
   alteration (a.k.a poisoning or tampering).

   This protection is done by cryptography means. To achieve this
   several new configuration directives had been developed (see
   attached README file) using them, user is able to configure
   ModSecurity to replace any outgoing cookies by new ones which
   transport original cookie contents encrypted using AES algorithm
   (on a private user defined encryption KEY). Or generate protection
   cookies that protect original ones by signing their contents.

   - URL protection (and forced browsing):
   New directives also enable URL encryption/signing (AES too and
   HMAC-SHA1).

   Using this feature original URLs are replaced by encrypted ones
   making client browsing totally opaque. This mechanism provides not
   only hiding of actual URL components, but also enables a method to
   avoid URL tampering.In case any modifications is done over the
   encrypted URL, ModSecurity will fail to decrypt it and then
   silently discard it taking the configured default error action.

DISCLAIMER

This version is an early development release,it is not very much
tested so your mileage will vary.This initial release is not intended
for production systems, but only for testing purposes.

Attached to this there is a patch against ModSecurity 1.9.4, a full
sourcecode tarball for the crypto empowered ModSecurity and also a
package containing source documentation code generated with doxygen.

Inside both (patch and full source) there is a README documentation
file with biref functionality description and instructions about using
new features and relates directives added for its use in ModSecurity.

Anyway, we are working in more features and looking forward to
contribute with some more efforts to ModSecurity code.

We are also working in 2.0.x migration (expected to be ready soon).

Please, everybody is welcome to test this code and tell us their
impressions and eventually bugs.... Any ideas/comments about new
features to be added will be greatly appreciated and for sure be studied.

Thanks to Ivan for his help, patience and impressive work in
ModSecurity, and also to you Ryan for your huge work in security
from which we all always learn.

Best Regards,

Ryan Barnett escribió:
> > Ivan,
> > In the summary, he states the following -
> >
> > /To compete in this market, ModSecurity must add the key missing
> > functionalities, such as automatic policy learning and *cookie,
URL, and
> > parameter protection*/.
> >
> > What was he referring to?  ModSecurity currently has the capability to
> > create filters (either positive/negative) for cookies, URLs and
> > parameters.  What am I missing here?  What did they test in order to
> > make that statement?
> >
> > Other than that, congrats to you on the success of ModSecurity!  It is
> > an outstanding app and you done an incredible job in both
developing and
> > supporting it.
> >
> > Keep up the fantastic work.
> >
> > --
> > Ryan C. Barnett
> > Web Application Security Consortium (WASC) Member
> > CIS Apache Benchmark Project Lead
> > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> > Author: Preventing Web Attacks with Apache
> >
-- _________________________________ Daniel Fernández Bleda Gerente de
cuentas Consultor en Seguridad CISA, CISSP, ISO27001 Lead Auditor
OPSA/OPST Trainer, CHFI Instructor dfernandez <at> isecauditors.com
Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com


CRYPTO FACILITIES FOR ModSecurity
---------------------------------

CREDITS:

ModSecurity for Apache 2.x, http://www.modsecurity.org/
ModSecurity and mod_security are trademarks of Thinking Stone Ltd
Copyright (c) 2002-2006 Thinking Stone (http://www.thinkingstone.com)

Nor Carles Bonamusa author of this patch, neither Internet Security
Auditors ( http://www.isecauditors.com) Auditors are associated
with Thinking Stone Ltd.


This patch contains Crypto enhancements for ModSecurity, it has been
developed by Internet Security Auditors ( http://www.isecauditors.com)
send any comments to Carles Bonamusa, soporte at isecauditors.com.

LICENSE:

This patch is free software (as well as it is mod_security of which this
is a derivative work) you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

DISCLAIMER:

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
details.

WARNING:

Current version is an early development release, namely "pre-alpha" release.
According to this,it is not very much tested so be aware of it's high
unstable status. This initial release is not intended for production systems,
but only for testing purposes.

We at Internet Security Auditors are glade to contribute this new features to
ModSecurity community hoping this will be useful to anyone  who may be
willing to try it. Any feedback will be greatly appreciated (use ModSecurity
mailing list, or contact soporte at isecauditors.com).

DESCRIPTION:

Intro:

This patch enhances mod_security to be able to apply cryptography to  its web
application firewall tasks. This effort has been deployed covering two areas:

        - Cookie protection.
        - Url protection (and forced browsing).

Cookie Protection:

As defined by reference standards  session state information ,'cookies', is
transferred in clear text between client and server. In addition this data
may also be cached by user-agent at client side in order to make it available
in future connections.

Being this mechanism used by web applications to gather and manage client
session information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by server
side and stored by the client. Then within normal client-server
communication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by the
client in his subsequent requests is trusted as far as  it's considered
generated by server application itself.

Within this scenario and provided that the standard mechanism does not offer
any integrity checking capabilities, a malicious attacker may be able to
modify cookie content trying to alter normal server application response into
his benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is a
task left to server web applications. So this security aspect completely
relies on server-side handling, that is, when server is given some cookie
information attached to a request, it is supposed to check for that data to
be correct.

Due to this settlement there is a duplication of effort implied by this
framework because every application will eventually need to code cookie
checking functionality.

The goal of this patch is enhance mod_security by adding functionalities to
protect web applications that use cookies as state management mechanism
against cookie modification (a.k.a poisoning or tampering).   This protection
is done by cryptography means. To achieve this several new configuration
directives had been developed (see detailed description below) using them ,
user is able to enable mod_security to replace any outgoing issued cookie by
a new one which transports original cookie contents encrypted using AES
algorithm using a private user defined  encryption KEY.

An important aspect to take into account is that this protection is intended
to be as much transparent as possible to protected applications. Doing it
this way, those applications will not need to be aware of this
countermeasures (so no modification/adaptation needed to run'behind' mod
security). Due to this, if a web application needs client-side access to
cookie stored values,  this encryption method will cause it to stop working
because cookies at  the browser side will be stored in encrypted format. To
overcome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security will
issue a new seal cookie for every original cookie sent by the protected
server. In this new cookie an HMAC-SHA1 hash will be stored protecting
original cookie contents against malicious modification.

Url protection (and forced browsing):

Another point where web applications are vulnerable is concerning url format.
Indeed many applications use url parameter passing to communicate and
transmit information. In those scenarios, malicious url modifications can
lead a clever attacker to crash,abuse or exploit the application. This
situations can result in information leaks, impersonation, etc...  To
increase mod_security capabilities, new directives have been added to enable
url encryption. Using this feature original url's are replaced by encrypted
ones  making client browsing totally opaque. This mechanism provides not only
hidding of  actual url components, but also enables a method to avoid url
tampering.In case  any modifications is done over the encrypted url,
mod_security will fail to decrypt it and then silently discard it taking the
configured default error action.

With the aim of making this new functionalities more flexible and useful,
supplied directives allow user to define when and where to apply this crypto
protection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches that
pattern will be identified as an entry point, and then will get protected
using encryption.

As done with cookies, there has been also provided a "softer" method to
protect links. Instead of Encrypting the url, user is capable of defining
Hashed entry points. When this mode is selected, for each uri processed that
match an entry point  pattern an HMAC-SHA1 hash is generated and added to it.
Then whenever a request is received containing this seal value, mod security
will recalculate the hash corresponding to received uri , checking it against
original assigned hash seal.

If it has been tampered, hash would not be equal to the provided originally
and  that would cause mod_security to reject the request.

Crypto Notes:

Both previously described facilities rely on simmetric key cryptography. That
is why it is so important to select good crypto keys, and change them often
in order to  reduce the time window for a brute force attack. To this end,
this patch supplies a built-in capability to generate crypto keys, and
provides a way to configure key validity period to customize it to suit any
scenario. (so is to say, setting short periods for high traffic sites, or
long ones for sites with less request ratio).


REQUIREMENTS:

* CRYPTLIB:

Encryption enhancements rely on routines provided by cryptlib, so in order  to
be able to build the module, a proper installation of cryptlib is needed. As
a rule of thumb it should work whether you use a shared library supplied by
your preferred distribution, or you may deploy your own installation.

For downloads and further information:
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

* LIBXML2:
Html parsing is built on top of libxml2 tools, so you need to have it
installed on your system. Again you can use your distribution library package
or you may install it from sources:

For downloads and further information:
http://xmlsoft.org/downloads.html

* APACHE HTTP SERVER And LIBAPR (sources or at least development headers)

As this in the end is an apache-httpd module, you'll need a suitable build
environment, being it provided by your distribution apache-devel packages or
supplied by a raw installation from upstream sources.

For downloads and further information:
http://httpd.apache.org/

IMPORTANT NOTE: This patch is provided only against mod_security for apache
2.0,
        there is no provided code for mod_security for apache 1.3. Any way as we're
supplying the code, the door is wide open to anyone willing contribute and
backport this code to work with apache 1.3.

INSTALLATION:
1 - Get a fresh copy of modsecurity version 1.9.4
        wget http://www.modsecurity.org/download/modsecurity-apache_1.9.4.tar.gz

2 - Extract it
        tar -xvzf /modsecurity-apache_1.9.4.tar.gz

3 - Apply patch
        cd modsecurity-apache_1.9.4
        bzcat path/to/crypto-patch-0.01-for-modsecurity_1.9.4.diff.bz2 | patch -p1

4 - Edit Makefile :

* Configure headers an library paths according to apache
http server settings on your site:

top_dir         = /path/to/installed/apache-2.0.XX
top_srcdir      = /path/to/sources/apache- 2.0.XX
top_builddir    = ${top_srcdir}

* If you're using libraries outside of standard locations yo may need to
configure also cryptlib and libxml paths (if they are not propperly resolved
by your environment settings):

cryptlib_srcdir = /path/to/cryptlib/sources
libxml2_srcdir  = /path/to/libxml/sources

5 - Run make, make install.

6 - If no errors are issued, you're ready to start using crypto enhancements.
To do so you must enable and configure them in your httpd.conf file.
(obviously you must add a LoadModule directive for mod_security)

Related keywords are:

        -SecCryptoEngine [ On | Off ]
                To enable disable Encryption Engine.
                example:
                        SecCryptoEngine On

        -SecCryptoCookies [ CookieSeal | CookieEncrypt ] ["default_actionset"]
                To enable cookie protection:
                        When Using CookieSeal, issued cookies will be protected with a new
                        generated cookie seal. Both cookies are sent to client browser so
                        applications that access them at client side are able to do so. When new
                        requests are made, received cookies at server side are checked against its
                        corresponding seal to prevent cookie tampering. In case received cookies
                        are found corrupt, they Are transparently suppressed and default actionset
                        is taken if defined (global error default actionset is assumed if no                            i
                        actionset is provided) .
                        example:
                                SecCryptoCookies CookieSeal "log,redirect:http://www.example.com "

                        When using CookieEncrypt mode, cookies issued by protected app are replaced
                        with encrypted ones which hold the same information. In this mode
                        application can't access cookies at client side (because they're ncrypted).
                        When in subsequent requests they're sent back to the server, mod_security
                        will seamlessly decrypt them rebuilding the original cookie contents to
                        deliver it to the sender app. As in the previous mode, application is
                        protected because any received cookie which fails to be decrypted, is
                        immediately removed causing request to be treated as specified in actionset
                        parameter (or global default actionset if none is supplied).

                        example:
                                SecCryptoCookies CookieEncrypt "log,redirect:http://www.example.com"

    -SecCryptoLinksEntryPoint [LinkHash | LinkEncrypt] "regular_expression"
                        To enable link protection by defining an entry point. This configuration
                        implies that any outgoing served page will be scanned in order to spot
                        instances of links that match the given pattern (regular expression). Those
                        items found will be treated as entry points and will get processed
                        according to specified mode.

                        If encription is choosen, link will be replaced by refurbished uri formated
                        like this:


http://www.example.com/SEC_DATA/<chunk_of_data_corresponding_to_encrypted_original_link>

                        When in subsequent client activity this request is issued back to the
                        server, mod_security will seamlessly decrypt this uri rebuilding the
                        original one that will be then sent to the the backend server. If any
                        modification has been done to the url, it will fail to decrypt causing
                        mod_security to discard it and take global default action or customized
                        particular action defined by SecCryptoEncryptedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkEncrypt "/path/to/site/administration"

                        If sealing is choosen, link will be replaced by refurbished where a
                        new "security seal" has been added : (uri will be formated like this)


http://www.example.com/path/to/file.html?SEC_DATA=<HMAC_SHA1_HASH_of_original_link>

                        When in later client petitions this request is issued back to the server,
                        mod_security will seamlessly recalculate hash for provided uri matching it
                        against SEC_DATA parameter. If any modification has been done to the url,
                        it will fail to match the seal causing mod_security to discard it and take
                        global default action or customized particular action defined by
                        SecCryptoHashedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkHash "/path/to/site/shopping-cart"

    -SecCryptoEncryptedLinksDefaultAction "default actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but is not
                itself encrypted.

                example:
                        SecCryptoEncryptedLinksDefaultAction "log,redirect:http://www.example.com"

    - SecCryptoHashedLinksDefaultAction "default_actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but uri do not
                match provided seal.

                example:
                        SecCryptoHashedLinksDefaultAction "log,redirect:http://www.example.com"

    - SecCryptoEncryptKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                encryption ). By default mod_security is set to renew encryption keys every
                600 seconds.

                example:
                        SecCryptoEncryptKeyRenewalPeriod 300

    - SecCryptoHashKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                HMAC-SH1 hashing ). By default mod_security is set to renew encryption keys
                every 600 seconds.

                example:
                        SecCryptoHashKeyRenewalPeriod 300



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users





Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Kim | 9 Jul 11:46 2006
Picon

Re: Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

 
Thought we get all the crypto features through mod-ssl, why do we need to extend mod-security for cookie and URL encryption.
 
But in general I like user contributed extensions or featues to mod-security. Is there any manual to understand mod-security design, flow etc. Fortunately it is based on apache, which has some documentation and framework for extenstions. What is the criteria to get selected to be part of modsecurity or kicked out :)
 
 

Ryan Barnett <rcbarnett <at> gmail.com> wrote:
Thanks for the info.  I had seen some presentation info (PPT or PDF) for a talk that I think you gave on this subject awhile ago, but there was no code available.  I will certainly try this out.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 7/7/06, Daniel Fdez. Bleda <dfernandez <at> isecauditors.com> wrote:
Ryan,

As Ivan explained, those functionalities refer to the use of
cryptography to avoid URL alteration, resource guessing,
cookie alteration, etc.

We at Internet Security Auditors have been using for some time
ModSecurity.

It has proven to be a great tool. From our experience in security
assessment, we've found some areas concerning web application security
that lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it by
extending it to suit our needs to provide better services to our
customers.

We have been working on that for some months and now (missing deep
performance and security testing which are next items in our agenda),
we'd like to advance some code to make this functionalities available
to ModSecurity 1.9.X. users.

This code is a proof of concept almost functional. As I've already
said, it has not been fully tested. Our intention is that ModSecurity
users do a some beta testing and report problems that eventually will
emerge (as is being done with ModSecurity itself).

We're glade to contribute some new features to ModSecurity community
hoping they may be useful to anyone who may be willing to add strong
cryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, but
not to disturb normal list usage, if you anyone is planning to submit
error logs or patches, you can contact us at support at isecauditors.com).

We expect, after a deep review and acceptance from Ivan Ristik, this
functionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancing
ModSecurity to be able to apply cryptography to its web application
firewall tasks.

This effort has been deployed covering two areas:

   - Cookie protection:

   Functionalities have been added to protect web applications that
   use cookies as state management mechanism against cookie
   alteration (a.k.a poisoning or tampering).

   This protection is done by cryptography means. To achieve this
   several new configuration directives had been developed (see
   attached README file) using them, user is able to configure
   ModSecurity to replace any outgoing cookies by new ones which
   transport original cookie contents encrypted using AES algorithm
   (on a private user defined encryption KEY). Or generate protection
   cookies that protect original ones by signing their contents.

   - URL protection (and forced browsing):
   New directives also enable URL encryption/signing (AES too and
   HMAC-SHA1).

   Using this feature original URLs are replaced by encrypted ones
   making client browsing totally opaque. This mechanism provides not
   only hiding of actual URL components, but also enables a method to
   avoid URL tampering.In case any modifications is done over the
   encrypted URL, ModSecurity will fail to decrypt it and then
   silently discard it taking the configured default error action.

DISCLAIMER

This version is an early development release,it is not very much
tested so your mileage will vary.This initial release is not intended
for production systems, but only for testing purposes.

Attached to this there is a patch against ModSecurity 1.9.4, a full
sourcecode tarball for the crypto empowered ModSecurity and also a
package containing source documentation code generated with doxygen.

Inside both (patch and full source) there is a README documentation
file with biref functionality description and instructions about using
new features and relates directives added for its use in ModSecurity.

Anyway, we are working in more features and looking forward to
contribute with some more efforts to ModSecurity code.

We are also working in 2.0.x migration (expected to be ready soon).

Please, everybody is welcome to test this code and tell us their
impressions and eventually bugs.... Any ideas/comments about new
features to be added will be greatly appreciated and for sure be studied.

Thanks to Ivan for his help, patience and impressive work in
ModSecurity, and also to you Ryan for your huge work in security
from which we all always learn.

Best Regards,

Ryan Barnett escribió:
> > Ivan,
> > In the summary, he states the following -
> >
> > /To compete in this market, ModSecurity must add the key missing
> > functionalities, such as automatic policy learning and *cookie,
URL, and
> > parameter protection*/.
> >
> > What was he referring to?  ModSecurity currently has the capability to
> > create filters (either positive/negative) for cookies, URLs and
> > parameters.  What am I missing here?  What did they test in order to
> > make that statement?
> >
> > Other than that, congrats to you on the success of ModSecurity!  It is
> > an outstanding app and you done an incredible job in both
developing and
> > supporting it.
> >
> > Keep up the fantastic work.
> >
> > --
> > Ryan C. Barnett
> > Web Application Security Consortium (WASC) Member
> > CIS Apache Benchmark Project Lead
> > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> > Author: Preventing Web Attacks with Apache
> >
-- _________________________________ Daniel Fernández Bleda Gerente de
cuentas Consultor en Seguridad CISA, CISSP, ISO27001 Lead Auditor
OPSA/OPST Trainer, CHFI Instructor dfernandez <at> isecauditors.com
Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com


CRYPTO FACILITIES FOR ModSecurity
---------------------------------

CREDITS:

ModSecurity for Apache 2.x, http://www.modsecurity.org/
ModSecurity and mod_security are trademarks of Thinking Stone Ltd
Copyright (c) 2002-2006 Thinking Stone (http://www.thinkingstone.com)

Nor Carles Bonamusa author of this patch, neither Internet Security
Auditors ( http://www.isecauditors.com) Auditors are associated
with Thinking Stone Ltd.


This patch contains Crypto enhancements for ModSecurity, it has been
developed by Internet Security Auditors ( http://www.isecauditors.com)
send any comments to Carles Bonamusa, soporte at isecauditors.com.

LICENSE:

This patch is free software (as well as it is mod_security of which this
is a derivative work) you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

DISCLAIMER:

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
details.

WARNING:

Current version is an early development release, namely "pre-alpha" release.
According to this,it is not very much tested so be aware of it's high
unstable status. This initial release is not intended for production systems,
but only for testing purposes.

We at Internet Security Auditors are glade to contribute this new features to
ModSecurity community hoping this will be useful to anyone  who may be
willing to try it. Any feedback will be greatly appreciated (use ModSecurity
mailing list, or contact soporte at isecauditors.com).

DESCRIPTION:

Intro:

This patch enhances mod_security to be able to apply cryptography to  its web
application firewall tasks. This effort has been deployed covering two areas:

        - Cookie protection.
        - Url protection (and forced browsing).

Cookie Protection:

As defined by reference standards  session state information ,'cookies', is
transferred in clear text between client and server. In addition this data
may also be cached by user-agent at client side in order to make it available
in future connections.

Being this mechanism used by web applications to gather and manage client
session information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by server
side and stored by the client. Then within normal client-server
communication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by the
client in his subsequent requests is trusted as far as  it's considered
generated by server application itself.

Within this scenario and provided that the standard mechanism does not offer
any integrity checking capabilities, a malicious attacker may be able to
modify cookie content trying to alter normal server application response into
his benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is a
task left to server web applications. So this security aspect completely
relies on server-side handling, that is, when server is given some cookie
information attached to a request, it is supposed to check for that data to
be correct.

Due to this settlement there is a duplication of effort implied by this
framework because every application will eventually need to code cookie
checking functionality.

The goal of this patch is enhance mod_security by adding functionalities to
protect web applications that use cookies as state management mechanism
against cookie modification (a.k.a poisoning or tampering).   This protection
is done by cryptography means. To achieve this several new configuration
directives had been developed (see detailed description below) using them ,
user is able to enable mod_security to replace any outgoing issued cookie by
a new one which transports original cookie contents encrypted using AES
algorithm using a private user defined  encryption KEY.

An important aspect to take into account is that this protection is intended
to be as much transparent as possible to protected applications. Doing it
this way, those applications will not need to be aware of this
countermeasures (so no modification/adaptation needed to run'behind' mod
security). Due to this, if a web application needs client-side access to
cookie stored values,  this encryption method will cause it to stop working
because cookies at  the browser side will be stored in encrypted format. To
overcome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security will
issue a new seal cookie for every original cookie sent by the protected
server. In this new cookie an HMAC-SHA1 hash will be stored protecting
original cookie contents against malicious modification.

Url protection (and forced browsing):

Another point where web applications are vulnerable is concerning url format.
Indeed many applications use url parameter passing to communicate and
transmit information. In those scenarios, malicious url modifications can
lead a clever attacker to crash,abuse or exploit the application. This
situations can result in information leaks, impersonation, etc...  To
increase mod_security capabilities, new directives have been added to enable
url encryption. Using this feature original url's are replaced by encrypted
ones  making client browsing totally opaque. This mechanism provides not only
hidding of  actual url components, but also enables a method to avoid url
tampering.In case  any modifications is done over the encrypted url,
mod_security will fail to decrypt it and then silently discard it taking the
configured default error action.

With the aim of making this new functionalities more flexible and useful,
supplied directives allow user to define when and where to apply this crypto
protection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches that
pattern will be identified as an entry point, and then will get protected
using encryption.

As done with cookies, there has been also provided a "softer" method to
protect links. Instead of Encrypting the url, user is capable of defining
Hashed entry points. When this mode is selected, for each uri processed that
match an entry point  pattern an HMAC-SHA1 hash is generated and added to it.
Then whenever a request is received containing this seal value, mod security
will recalculate the hash corresponding to received uri , checking it against
original assigned hash seal.

If it has been tampered, hash would not be equal to the provided originally
and  that would cause mod_security to reject the request.

Crypto Notes:

Both previously described facilities rely on simmetric key cryptography. That
is why it is so important to select good crypto keys, and change them often
in order to  reduce the time window for a brute force attack. To this end,
this patch supplies a built-in capability to generate crypto keys, and
provides a way to configure key validity period to customize it to suit any
scenario. (so is to say, setting short periods for high traffic sites, or
long ones for sites with less request ratio).


REQUIREMENTS:

* CRYPTLIB:

Encryption enhancements rely on routines provided by cryptlib, so in order  to
be able to build the module, a proper installation of cryptlib is needed. As
a rule of thumb it should work whether you use a shared library supplied by
your preferred distribution, or you may deploy your own installation.

For downloads and further information:
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

* LIBXML2:
Html parsing is built on top of libxml2 tools, so you need to have it
installed on your system. Again you can use your distribution library package
or you may install it from sources:

For downloads and further information:
http://xmlsoft.org/downloads.html

* APACHE HTTP SERVER And LIBAPR (sources or at least development headers)

As this in the end is an apache-httpd module, you'll need a suitable build
environment, being it provided by your distribution apache-devel packages or
supplied by a raw installation from upstream sources.

For downloads and further information:
http://httpd.apache.org/

IMPORTANT NOTE: This patch is provided only against mod_security for apache
2.0,
        there is no provided code for mod_security for apache 1.3. Any way as we're
supplying the code, the door is wide open to anyone willing contribute and
backport this code to work with apache 1.3.

INSTALLATION:
1 - Get a fresh copy of modsecurity version 1.9.4
        wget http://www.modsecurity.org/download/modsecurity-apache_1.9.4.tar.gz

2 - Extract it
        tar -xvzf /modsecurity-apache_1.9.4.tar.gz

3 - Apply patch
        cd modsecurity-apache_1.9.4
        bzcat path/to/crypto-patch-0.01-for-modsecurity_1.9.4.diff.bz2 | patch -p1

4 - Edit Makefile :

* Configure headers an library paths according to apache
http server settings on your site:

top_dir         = /path/to/installed/apache-2.0.XX
top_srcdir      = /path/to/sources/apache- 2.0.XX
top_builddir    = ${top_srcdir}

* If you're using libraries outside of standard locations yo may need to
configure also cryptlib and libxml paths (if they are not propperly resolved
by your environment settings):

cryptlib_srcdir = /path/to/cryptlib/sources
libxml2_srcdir  = /path/to/libxml/sources

5 - Run make, make install.

6 - If no errors are issued, you're ready to start using crypto enhancements.
To do so you must enable and configure them in your httpd.conf file.
(obviously you must add a LoadModule directive for mod_security)

Related keywords are:

        -SecCryptoEngine [ On | Off ]
                To enable disable Encryption Engine.
                example:
                        SecCryptoEngine On

        -SecCryptoCookies [ CookieSeal | CookieEncrypt ] ["default_actionset"]
                To enable cookie protection:
                        When Using CookieSeal, issued cookies will be protected with a new
                        generated cookie seal. Both cookies are sent to client browser so
                        applications that access them at client side are able to do so. When new
                        requests are made, received cookies at server side are checked against its
                        corresponding seal to prevent cookie tampering. In case received cookies
                        are found corrupt, they Are transparently suppressed and default actionset
                        is taken if defined (global error default actionset is assumed if no                            i
                        actionset is provided) .
                        example:
                                SecCryptoCookies CookieSeal "log,redirect:http://www.example.com "

                        When using CookieEncrypt mode, cookies issued by protected app are replaced
                        with encrypted ones which hold the same information. In this mode
                        application can't access cookies at client side (because they're ncrypted).
                        When in subsequent requests they're sent back to the server, mod_security
                        will seamlessly decrypt them rebuilding the original cookie contents to
                        deliver it to the sender app. As in the previous mode, application is
                        protected because any received cookie which fails to be decrypted, is
                        immediately removed causing request to be treated as specified in actionset
                        parameter (or global default actionset if none is supplied).

                        example:
                                SecCryptoCookies CookieEncrypt "log,redirect:http://www.example.com"

    -SecCryptoLinksEntryPoint [LinkHash | LinkEncrypt] "regular_expression"
                        To enable link protection by defining an entry point. This configuration
                        implies that any outgoing served page will be scanned in order to spot
                        instances of links that match the given pattern (regular expression). Those
                        items found will be treated as entry points and will get processed
                        according to specified mode.

                        If encription is choosen, link will be replaced by refurbished uri formated
                        like this:


http://www.example.com/SEC_DATA/<chunk_of_data_corresponding_to_encrypted_original_link>

                        When in subsequent client activity this request is issued back to the
                        server, mod_security will seamlessly decrypt this uri rebuilding the
                        original one that will be then sent to the the backend server. If any
                        modification has been done to the url, it will fail to decrypt causing
                        mod_security to discard it and take global default action or customized
                        particular action defined by SecCryptoEncryptedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkEncrypt "/path/to/site/administration"

                        If sealing is choosen, link will be replaced by refurbished where a
                        new "security seal" has been added : (uri will be formated like this)


http://www.example.com/path/to/file.html?SEC_DATA=<HMAC_SHA1_HASH_of_original_link>

                        When in later client petitions this request is issued back to the server,
                        mod_security will seamlessly recalculate hash for provided uri matching it
                        against SEC_DATA parameter. If any modification has been done to the url,
                        it will fail to match the seal causing mod_security to discard it and take
                        global default action or customized particular action defined by
                        SecCryptoHashedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkHash "/path/to/site/shopping-cart"

    -SecCryptoEncryptedLinksDefaultAction "default actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but is not
                itself encrypted.

                example:
                        SecCryptoEncryptedLinksDefaultAction "log,redirect:http://www.example.com"

    - SecCryptoHashedLinksDefaultAction "default_actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but uri do not
                match provided seal.

                example:
                        SecCryptoHashedLinksDefaultAction "log,redirect:http://www.example.com"

    - SecCryptoEncryptKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                encryption ). By default mod_security is set to renew encryption keys every
                600 seconds.

                example:
                        SecCryptoEncryptKeyRenewalPeriod 300

    - SecCryptoHashKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                HMAC-SH1 hashing ). By default mod_security is set to renew encryption keys
                every 600 seconds.

                example:
                        SecCryptoHashKeyRenewalPeriod 300



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users





Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ryan Barnett | 9 Jul 21:48 2006
Picon

Re: Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

The encryption provided by mod_ssl will provide confidentiality of the network traffic against 3rd party sniffing.  The 2 encryption extensions for modsecurity that Daniel presented are to protect against attacks that someone can attempt when interacting with the web app directly (whether it is over SSL or not). 
 
The 2 main threats that these settings will help to protect against are -
 
1) Cookie Tampering - if cookie have weak encoding and or use plaintext data to define user roles (such as Cookie: user=bob; JSESSIONID=394r9hnfnq0ongf..) then an attacker may be able to alter the data to achieve a privlege escalation or session hijacking attack.  In the example cookie above, what if an attacker logs into the web app as themselves.  There is a valid session cookie (JSESSIONID) and then the app is tracking the attacker's specific role by setting and reading the "user=" cookie.  What happens if the attacker then attempts to change the "user=bob" data to say, "user=alice" or "user=admin"?
 
2) Forceful Browsing - is when a user/attacker simply type data into the URL field of their browser and attempt to access data directly rather than following links.  Attackers can usually make educated guesses based on the current URL structure as to the names of other possible "interesting" directories/files.
 
I can speak from first hand experience when running web assessments that these 2 issues can cause major problems with information disclosure, etc...
 
Keep in mind that the sole reason that these attacks are possible is that the data presented to the client is in clear text and therefore provides enough intelligence to allow the attacker to tamper with data.  The web application firewall vendors realized this threat and some of them have implemented this feature already.  Take a look at the WASC Web Application Firewall Evaluation Criteria for more info - http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html#N103B9
 
Hope this info helps to clarify the rationale and need for this type of protection.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

 
On 7/9/06, Kim <kim.galieo <at> yahoo.com> wrote:
 
Thought we get all the crypto features through mod-ssl, why do we need to extend mod-security for cookie and URL encryption.
 
But in general I like user contributed extensions or featues to mod-security. Is there any manual to understand mod-security design, flow etc. Fortunately it is based on apache, which has some documentation and framework for extenstions. What is the criteria to get selected to be part of modsecurity or kicked out :)
 
 

Ryan Barnett <rcbarnett <at> gmail.com> wrote:
Thanks for the info.  I had seen some presentation info (PPT or PDF) for a talk that I think you gave on this subject awhile ago, but there was no code available.  I will certainly try this out.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 7/7/06, Daniel Fdez. Bleda <dfernandez <at> isecauditors.com > wrote:
Ryan,

As Ivan explained, those functionalities refer to the use of
cryptography to avoid URL alteration, resource guessing,
cookie alteration, etc.

We at Internet Security Auditors have been using for some time
ModSecurity.

It has proven to be a great tool. From our experience in security
assessment, we've found some areas concerning web application security
that lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it by
extending it to suit our needs to provide better services to our
customers.

We have been working on that for some months and now (missing deep
performance and security testing which are next items in our agenda),
we'd like to advance some code to make this functionalities available
to ModSecurity 1.9.X. users.

This code is a proof of concept almost functional. As I've already
said, it has not been fully tested. Our intention is that ModSecurity
users do a some beta testing and report problems that eventually will
emerge (as is being done with ModSecurity itself).

We're glade to contribute some new features to ModSecurity community
hoping they may be useful to anyone who may be willing to add strong
cryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, but
not to disturb normal list usage, if you anyone is planning to submit
error logs or patches, you can contact us at support at isecauditors.com).

We expect, after a deep review and acceptance from Ivan Ristik, this
functionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancing
ModSecurity to be able to apply cryptography to its web application
firewall tasks.

This effort has been deployed covering two areas:

   - Cookie protection:

   Functionalities have been added to protect web applications that
   use cookies as state management mechanism against cookie
   alteration (a.k.a poisoning or tampering).

   This protection is done by cryptography means. To achieve this
   several new configuration directives had been developed (see
   attached README file) using them, user is able to configure
   ModSecurity to replace any outgoing cookies by new ones which
   transport original cookie contents encrypted using AES algorithm
   (on a private user defined encryption KEY). Or generate protection
   cookies that protect original ones by signing their contents.

   - URL protection (and forced browsing):
   New directives also enable URL encryption/signing (AES too and
   HMAC-SHA1).

   Using this feature original URLs are replaced by encrypted ones
   making client browsing totally opaque. This mechanism provides not
   only hiding of actual URL components, but also enables a method to
   avoid URL tampering.In case any modifications is done over the
   encrypted URL, ModSecurity will fail to decrypt it and then
   silently discard it taking the configured default error action.

DISCLAIMER

This version is an early development release,it is not very much
tested so your mileage will vary.This initial release is not intended
for production systems, but only for testing purposes.

Attached to this there is a patch against ModSecurity 1.9.4, a full
sourcecode tarball for the crypto empowered ModSecurity and also a
package containing source documentation code generated with doxygen.

Inside both (patch and full source) there is a README documentation
file with biref functionality description and instructions about using
new features and relates directives added for its use in ModSecurity.

Anyway, we are working in more features and looking forward to
contribute with some more efforts to ModSecurity code.

We are also working in 2.0.x migration (expected to be ready soon).

Please, everybody is welcome to test this code and tell us their
impressions and eventually bugs.... Any ideas/comments about new
features to be added will be greatly appreciated and for sure be studied.

Thanks to Ivan for his help, patience and impressive work in
ModSecurity, and also to you Ryan for your huge work in security
from which we all always learn.

Best Regards,

Ryan Barnett escribió:
> > Ivan,
> > In the summary, he states the following -
> >
> > /To compete in this market, ModSecurity must add the key missing
> > functionalities, such as automatic policy learning and *cookie,
URL, and
> > parameter protection*/.
> >
> > What was he referring to?  ModSecurity currently has the capability to
> > create filters (either positive/negative) for cookies, URLs and
> > parameters.  What am I missing here?  What did they test in order to
> > make that statement?
> >
> > Other than that, congrats to you on the success of ModSecurity!  It is
> > an outstanding app and you done an incredible job in both
developing and
> > supporting it.
> >
> > Keep up the fantastic work.
> >
> > --
> > Ryan C. Barnett
> > Web Application Security Consortium (WASC) Member
> > CIS Apache Benchmark Project Lead
> > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> > Author: Preventing Web Attacks with Apache
> >
-- _________________________________ Daniel Fernández Bleda Gerente de
cuentas Consultor en Seguridad CISA, CISSP, ISO27001 Lead Auditor
OPSA/OPST Trainer, CHFI Instructor dfernandez <at> isecauditors.com
Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com


CRYPTO FACILITIES FOR ModSecurity
---------------------------------

CREDITS:

ModSecurity for Apache 2.x, http://www.modsecurity.org/
ModSecurity and mod_security are trademarks of Thinking Stone Ltd
Copyright (c) 2002-2006 Thinking Stone ( http://www.thinkingstone.com)

Nor Carles Bonamusa author of this patch, neither Internet Security
Auditors ( http://www.isecauditors.com) Auditors are associated
with Thinking Stone Ltd.


This patch contains Crypto enhancements for ModSecurity, it has been
developed by Internet Security Auditors ( http://www.isecauditors.com)
send any comments to Carles Bonamusa, soporte at isecauditors.com.

LICENSE:

This patch is free software (as well as it is mod_security of which this
is a derivative work) you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

DISCLAIMER:

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
details.

WARNING:

Current version is an early development release, namely "pre-alpha" release.
According to this,it is not very much tested so be aware of it's high
unstable status. This initial release is not intended for production systems,
but only for testing purposes.

We at Internet Security Auditors are glade to contribute this new features to
ModSecurity community hoping this will be useful to anyone  who may be
willing to try it. Any feedback will be greatly appreciated (use ModSecurity
mailing list, or contact soporte at isecauditors.com).

DESCRIPTION:

Intro:

This patch enhances mod_security to be able to apply cryptography to  its web
application firewall tasks. This effort has been deployed covering two areas:

        - Cookie protection.
        - Url protection (and forced browsing).

Cookie Protection:

As defined by reference standards  session state information ,'cookies', is
transferred in clear text between client and server. In addition this data
may also be cached by user-agent at client side in order to make it available
in future connections.

Being this mechanism used by web applications to gather and manage client
session information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by server
side and stored by the client. Then within normal client-server
communication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by the
client in his subsequent requests is trusted as far as  it's considered
generated by server application itself.

Within this scenario and provided that the standard mechanism does not offer
any integrity checking capabilities, a malicious attacker may be able to
modify cookie content trying to alter normal server application response into
his benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is a
task left to server web applications. So this security aspect completely
relies on server-side handling, that is, when server is given some cookie
information attached to a request, it is supposed to check for that data to
be correct.

Due to this settlement there is a duplication of effort implied by this
framework because every application will eventually need to code cookie
checking functionality.

The goal of this patch is enhance mod_security by adding functionalities to
protect web applications that use cookies as state management mechanism
against cookie modification (a.k.a poisoning or tampering).   This protection
is done by cryptography means. To achieve this several new configuration
directives had been developed (see detailed description below) using them ,
user is able to enable mod_security to replace any outgoing issued cookie by
a new one which transports original cookie contents encrypted using AES
algorithm using a private user defined  encryption KEY.

An important aspect to take into account is that this protection is intended
to be as much transparent as possible to protected applications. Doing it
this way, those applications will not need to be aware of this
countermeasures (so no modification/adaptation needed to run'behind' mod
security). Due to this, if a web application needs client-side access to
cookie stored values,  this encryption method will cause it to stop working
because cookies at  the browser side will be stored in encrypted format. To
overcome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security will
issue a new seal cookie for every original cookie sent by the protected
server. In this new cookie an HMAC-SHA1 hash will be stored protecting
original cookie contents against malicious modification.

Url protection (and forced browsing):

Another point where web applications are vulnerable is concerning url format.
Indeed many applications use url parameter passing to communicate and
transmit information. In those scenarios, malicious url modifications can
lead a clever attacker to crash,abuse or exploit the application. This
situations can result in information leaks, impersonation, etc...  To
increase mod_security capabilities, new directives have been added to enable
url encryption. Using this feature original url's are replaced by encrypted
ones  making client browsing totally opaque. This mechanism provides not only
hidding of  actual url components, but also enables a method to avoid url
tampering.In case  any modifications is done over the encrypted url,
mod_security will fail to decrypt it and then silently discard it taking the
configured default error action.

With the aim of making this new functionalities more flexible and useful,
supplied directives allow user to define when and where to apply this crypto
protection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches that
pattern will be identified as an entry point, and then will get protected
using encryption.

As done with cookies, there has been also provided a "softer" method to
protect links. Instead of Encrypting the url, user is capable of defining
Hashed entry points. When this mode is selected, for each uri processed that
match an entry point  pattern an HMAC-SHA1 hash is generated and added to it.
Then whenever a request is received containing this seal value, mod security
will recalculate the hash corresponding to received uri , checking it against
original assigned hash seal.

If it has been tampered, hash would not be equal to the provided originally
and  that would cause mod_security to reject the request.

Crypto Notes:

Both previously described facilities rely on simmetric key cryptography. That
is why it is so important to select good crypto keys, and change them often
in order to  reduce the time window for a brute force attack. To this end,
this patch supplies a built-in capability to generate crypto keys, and
provides a way to configure key validity period to customize it to suit any
scenario. (so is to say, setting short periods for high traffic sites, or
long ones for sites with less request ratio).


REQUIREMENTS:

* CRYPTLIB:

Encryption enhancements rely on routines provided by cryptlib, so in order  to
be able to build the module, a proper installation of cryptlib is needed. As
a rule of thumb it should work whether you use a shared library supplied by
your preferred distribution, or you may deploy your own installation.

For downloads and further information:
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

* LIBXML2:
Html parsing is built on top of libxml2 tools, so you need to have it
installed on your system. Again you can use your distribution library package
or you may install it from sources:

For downloads and further information:
http://xmlsoft.org/downloads.html

* APACHE HTTP SERVER And LIBAPR (sources or at least development headers)

As this in the end is an apache-httpd module, you'll need a suitable build
environment, being it provided by your distribution apache-devel packages or
supplied by a raw installation from upstream sources.

For downloads and further information:
http://httpd.apache.org/

IMPORTANT NOTE: This patch is provided only against mod_security for apache
2.0,
        there is no provided code for mod_security for apache 1.3. Any way as we're
supplying the code, the door is wide open to anyone willing contribute and
backport this code to work with apache 1.3.

INSTALLATION:
1 - Get a fresh copy of modsecurity version 1.9.4
        wget http://www.modsecurity.org/download/modsecurity-apache_1.9.4.tar.gz

2 - Extract it
        tar -xvzf /modsecurity-apache_1.9.4.tar.gz

3 - Apply patch
        cd modsecurity-apache_1.9.4
        bzcat path/to/crypto- patch-0.01-for-modsecurity_1.9.4.diff.bz2 | patch -p1

4 - Edit Makefile :

* Configure headers an library paths according to apache
http server settings on your site:

top_dir         = /path/to/installed/apache- 2.0.XX
top_srcdir      = /path/to/sources/apache- 2.0.XX
top_builddir    = ${top_srcdir}

* If you're using libraries outside of standard locations yo may need to
configure also cryptlib and libxml paths (if they are not propperly resolved
by your environment settings):

cryptlib_srcdir = /path/to/cryptlib/sources
libxml2_srcdir  = /path/to/libxml/sources

5 - Run make, make install.

6 - If no errors are issued, you're ready to start using crypto enhancements.
To do so you must enable and configure them in your httpd.conf file.
(obviously you must add a LoadModule directive for mod_security)

Related keywords are:

        -SecCryptoEngine [ On | Off ]
                To enable disable Encryption Engine.
                example:
                        SecCryptoEngine On

        -SecCryptoCookies [ CookieSeal | CookieEncrypt ] ["default_actionset"]
                To enable cookie protection:
                        When Using CookieSeal, issued cookies will be protected with a new
                        generated cookie seal. Both cookies are sent to client browser so
                        applications that access them at client side are able to do so. When new
                        requests are made, received cookies at server side are checked against its
                        corresponding seal to prevent cookie tampering. In case received cookies
                        are found corrupt, they Are transparently suppressed and default actionset
                        is taken if defined (global error default actionset is assumed if no                            i
                        actionset is provided) .
                        example:
                                SecCryptoCookies CookieSeal "log,redirect: http://www.example.com "

                        When using CookieEncrypt mode, cookies issued by protected app are replaced
                        with encrypted ones which hold the same information. In this mode
                        application can't access cookies at client side (because they're ncrypted).
                        When in subsequent requests they're sent back to the server, mod_security
                        will seamlessly decrypt them rebuilding the original cookie contents to
                        deliver it to the sender app. As in the previous mode, application is
                        protected because any received cookie which fails to be decrypted, is
                        immediately removed causing request to be treated as specified in actionset
                        parameter (or global default actionset if none is supplied).

                        example:
                                SecCryptoCookies CookieEncrypt "log,redirect:http://www.example.com"

    -SecCryptoLinksEntryPoint [LinkHash | LinkEncrypt] "regular_expression"
                        To enable link protection by defining an entry point. This configuration
                        implies that any outgoing served page will be scanned in order to spot
                        instances of links that match the given pattern (regular expression). Those
                        items found will be treated as entry points and will get processed
                        according to specified mode.

                        If encription is choosen, link will be replaced by refurbished uri formated
                        like this:


http://www.example.com/SEC_DATA/<chunk_of_data_corresponding_to_encrypted_original_link>

                        When in subsequent client activity this request is issued back to the
                        server, mod_security will seamlessly decrypt this uri rebuilding the
                        original one that will be then sent to the the backend server. If any
                        modification has been done to the url, it will fail to decrypt causing
                        mod_security to discard it and take global default action or customized
                        particular action defined by SecCryptoEncryptedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkEncrypt "/path/to/site/administration"

                        If sealing is choosen, link will be replaced by refurbished where a
                        new "security seal" has been added : (uri will be formated like this)


http://www.example.com/path/to/file.html?SEC_DATA=<HMAC_SHA1_HASH_of_original_link>

                        When in later client petitions this request is issued back to the server,
                        mod_security will seamlessly recalculate hash for provided uri matching it
                        against SEC_DATA parameter. If any modification has been done to the url,
                        it will fail to match the seal causing mod_security to discard it and take
                        global default action or customized particular action defined by
                        SecCryptoHashedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkHash "/path/to/site/shopping-cart"

    -SecCryptoEncryptedLinksDefaultAction "default actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but is not
                itself encrypted.

                example:
                        SecCryptoEncryptedLinksDefaultAction "log,redirect: http://www.example.com"

    - SecCryptoHashedLinksDefaultAction "default_actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but uri do not
                match provided seal.

                example:
                        SecCryptoHashedLinksDefaultAction "log,redirect: http://www.example.com"

    - SecCryptoEncryptKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                encryption ). By default mod_security is set to renew encryption keys every
                600 seconds.

                example:
                        SecCryptoEncryptKeyRenewalPeriod 300

    - SecCryptoHashKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                HMAC-SH1 hashing ). By default mod_security is set to renew encryption keys
                every 600 seconds.

                example:
                        SecCryptoHashKeyRenewalPeriod 300



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users





Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com



 
 

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Kim | 10 Jul 09:10 2006
Picon

Re: Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

 
Sorry for quick assumptions, I haven't read the all the details, cryptography took my head to SSL. It does make sense encrypting or signing the cookies and hidden fields in older implementation. We use jsp based middleware, we dont see cookie based user tracking. Obviously sessionID and sessiontable are good enough to implement role based access control, and prevent privilege escalation,  without sending cookies back forth for user identification.
 
What happens if an parameter that is being protected also needs to be manipulated/visible at the browser/client legitemately. To decrypt one has to share the keys and all issues related.  May be signing is an better option, we would know if it is changed. If cookie or parameter not going to change at client, why this needn't be sent back and forth.
 
I use a tool called httpanalyzer as IE plugin which shows me all the headers, cookies, querry strings for any URL that we visit, I didn't find any website doing cookie based user tracking. May be there are old applications like that.
 
I am interested in understanding how moidsecurity code works, would appreciate if any of you doing a small writeup on the design, flow and how to interface with it etc.
 
Thanks,

Ryan Barnett <rcbarnett <at> gmail.com> wrote:
The encryption provided by mod_ssl will provide confidentiality of the network traffic against 3rd party sniffing.  The 2 encryption extensions for modsecurity that Daniel presented are to protect against attacks that someone can attempt when interacting with the web app directly (whether it is over SSL or not). 
 
The 2 main threats that these settings will help to protect against are -
 
1) Cookie Tampering - if cookie have weak encoding and or use plaintext data to define user roles (such as Cookie: user=bob; JSESSIONID=394r9hnfnq0ongf..) then an attacker may be able to alter the data to achieve a privlege escalation or session hijacking attack.  In the example cookie above, what if an attacker logs into the web app as themselves.  There is a valid session cookie (JSESSIONID) and then the app is tracking the attacker's specific role by setting and reading the "user=" cookie.  What happens if the attacker then attempts to change the "user=bob" data to say, "user=alice" or "user=admin"?
 
2) Forceful Browsing - is when a user/attacker simply type data into the URL field of their browser and attempt to access data directly rather than following links.  Attackers can usually make educated guesses based on the current URL structure as to the names of other possible "interesting" directories/files.
 
I can speak from first hand experience when running web assessments that these 2 issues can cause major problems with information disclosure, etc...
 
Keep in mind that the sole reason that these attacks are possible is that the data presented to the client is in clear text and therefore provides enough intelligence to allow the attacker to tamper with data.  The web application firewall vendors realized this threat and some of them have implemented this feature already.  Take a look at the WASC Web Application Firewall Evaluation Criteria for more info - http://www.webappsec.org/projects/wafec/v1/wasc-wafec-v1.0.html#N103B9
 
Hope this info helps to clarify the rationale and need for this type of protection.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

 
On 7/9/06, Kim <kim.galieo <at> yahoo.com> wrote:
 
Thought we get all the crypto features through mod-ssl, why do we need to extend mod-security for cookie and URL encryption.
 
But in general I like user contributed extensions or featues to mod-security. Is there any manual to understand mod-security design, flow etc. Fortunately it is based on apache, which has some documentation and framework for extenstions. What is the criteria to get selected to be part of modsecurity or kicked out :)
 
 

Ryan Barnett <rcbarnett <at> gmail.com> wrote:
Thanks for the info.  I had seen some presentation info (PPT or PDF) for a talk that I think you gave on this subject awhile ago, but there was no code available.  I will certainly try this out.

--
Ryan C. Barnett
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache


On 7/7/06, Daniel Fdez. Bleda <dfernandez <at> isecauditors.com > wrote:
Ryan,

As Ivan explained, those functionalities refer to the use of
cryptography to avoid URL alteration, resource guessing,
cookie alteration, etc.

We at Internet Security Auditors have been using for some time
ModSecurity.

It has proven to be a great tool. From our experience in security
assessment, we've found some areas concerning web application security
that lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it by
extending it to suit our needs to provide better services to our
customers.

We have been working on that for some months and now (missing deep
performance and security testing which are next items in our agenda),
we'd like to advance some code to make this functionalities available
to ModSecurity 1.9.X. users.

This code is a proof of concept almost functional. As I've already
said, it has not been fully tested. Our intention is that ModSecurity
users do a some beta testing and report problems that eventually will
emerge (as is being done with ModSecurity itself).

We're glade to contribute some new features to ModSecurity community
hoping they may be useful to anyone who may be willing to add strong
cryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, but
not to disturb normal list usage, if you anyone is planning to submit
error logs or patches, you can contact us at support at isecauditors.com).

We expect, after a deep review and acceptance from Ivan Ristik, this
functionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancing
ModSecurity to be able to apply cryptography to its web application
firewall tasks.

This effort has been deployed covering two areas:

   - Cookie protection:

   Functionalities have been added to protect web applications that
   use cookies as state management mechanism against cookie
   alteration (a.k.a poisoning or tampering).

   This protection is done by cryptography means. To achieve this
   several new configuration directives had been developed (see
   attached README file) using them, user is able to configure
   ModSecurity to replace any outgoing cookies by new ones which
   transport original cookie contents encrypted using AES algorithm
   (on a private user defined encryption KEY). Or generate protection
   cookies that protect original ones by signing their contents.

   - URL protection (and forced browsing):
   New directives also enable URL encryption/signing (AES too and
   HMAC-SHA1).

   Using this feature original URLs are replaced by encrypted ones
   making client browsing totally opaque. This mechanism provides not
   only hiding of actual URL components, but also enables a method to
   avoid URL tampering.In case any modifications is done over the
   encrypted URL, ModSecurity will fail to decrypt it and then
   silently discard it taking the configured default error action.

DISCLAIMER

This version is an early development release,it is not very much
tested so your mileage will vary.This initial release is not intended
for production systems, but only for testing purposes.

Attached to this there is a patch against ModSecurity 1.9.4, a full
sourcecode tarball for the crypto empowered ModSecurity and also a
package containing source documentation code generated with doxygen.

Inside both (patch and full source) there is a README documentation
file with biref functionality description and instructions about using
new features and relates directives added for its use in ModSecurity.

Anyway, we are working in more features and looking forward to
contribute with some more efforts to ModSecurity code.

We are also working in 2.0.x migration (expected to be ready soon).

Please, everybody is welcome to test this code and tell us their
impressions and eventually bugs.... Any ideas/comments about new
features to be added will be greatly appreciated and for sure be studied.

Thanks to Ivan for his help, patience and impressive work in
ModSecurity, and also to you Ryan for your huge work in security
from which we all always learn.

Best Regards,

Ryan Barnett escribió:
> > Ivan,
> > In the summary, he states the following -
> >
> > /To compete in this market, ModSecurity must add the key missing
> > functionalities, such as automatic policy learning and *cookie,
URL, and
> > parameter protection*/.
> >
> > What was he referring to?  ModSecurity currently has the capability to
> > create filters (either positive/negative) for cookies, URLs and
> > parameters.  What am I missing here?  What did they test in order to
> > make that statement?
> >
> > Other than that, congrats to you on the success of ModSecurity!  It is
> > an outstanding app and you done an incredible job in both
developing and
> > supporting it.
> >
> > Keep up the fantastic work.
> >
> > --
> > Ryan C. Barnett
> > Web Application Security Consortium (WASC) Member
> > CIS Apache Benchmark Project Lead
> > SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
> > Author: Preventing Web Attacks with Apache
> >
-- _________________________________ Daniel Fernández Bleda Gerente de
cuentas Consultor en Seguridad CISA, CISSP, ISO27001 Lead Auditor
OPSA/OPST Trainer, CHFI Instructor dfernandez <at> isecauditors.com
Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2º 1ª.
08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com


CRYPTO FACILITIES FOR ModSecurity
---------------------------------

CREDITS:

ModSecurity for Apache 2.x, http://www.modsecurity.org/
ModSecurity and mod_security are trademarks of Thinking Stone Ltd
Copyright (c) 2002-2006 Thinking Stone ( http://www.thinkingstone.com)

Nor Carles Bonamusa author of this patch, neither Internet Security
Auditors ( http://www.isecauditors.com) Auditors are associated
with Thinking Stone Ltd.


This patch contains Crypto enhancements for ModSecurity, it has been
developed by Internet Security Auditors ( http://www.isecauditors.com)
send any comments to Carles Bonamusa, soporte at isecauditors.com.

LICENSE:

This patch is free software (as well as it is mod_security of which this
is a derivative work) you can redistribute it and/or modify it under the
terms of the GNU General Public License as published by the Free Software
Foundation; either version 2 of the License, or (at your option) any later
version.

DISCLAIMER:

This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
details.

WARNING:

Current version is an early development release, namely "pre-alpha" release.
According to this,it is not very much tested so be aware of it's high
unstable status. This initial release is not intended for production systems,
but only for testing purposes.

We at Internet Security Auditors are glade to contribute this new features to
ModSecurity community hoping this will be useful to anyone  who may be
willing to try it. Any feedback will be greatly appreciated (use ModSecurity
mailing list, or contact soporte at isecauditors.com).

DESCRIPTION:

Intro:

This patch enhances mod_security to be able to apply cryptography to  its web
application firewall tasks. This effort has been deployed covering two areas:

        - Cookie protection.
        - Url protection (and forced browsing).

Cookie Protection:

As defined by reference standards  session state information ,'cookies', is
transferred in clear text between client and server. In addition this data
may also be cached by user-agent at client side in order to make it available
in future connections.

Being this mechanism used by web applications to gather and manage client
session information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by server
side and stored by the client. Then within normal client-server
communication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by the
client in his subsequent requests is trusted as far as  it's considered
generated by server application itself.

Within this scenario and provided that the standard mechanism does not offer
any integrity checking capabilities, a malicious attacker may be able to
modify cookie content trying to alter normal server application response into
his benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is a
task left to server web applications. So this security aspect completely
relies on server-side handling, that is, when server is given some cookie
information attached to a request, it is supposed to check for that data to
be correct.

Due to this settlement there is a duplication of effort implied by this
framework because every application will eventually need to code cookie
checking functionality.

The goal of this patch is enhance mod_security by adding functionalities to
protect web applications that use cookies as state management mechanism
against cookie modification (a.k.a poisoning or tampering).   This protection
is done by cryptography means. To achieve this several new configuration
directives had been developed (see detailed description below) using them ,
user is able to enable mod_security to replace any outgoing issued cookie by
a new one which transports original cookie contents encrypted using AES
algorithm using a private user defined  encryption KEY.

An important aspect to take into account is that this protection is intended
to be as much transparent as possible to protected applications. Doing it
this way, those applications will not need to be aware of this
countermeasures (so no modification/adaptation needed to run'behind' mod
security). Due to this, if a web application needs client-side access to
cookie stored values,  this encryption method will cause it to stop working
because cookies at  the browser side will be stored in encrypted format. To
overcome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security will
issue a new seal cookie for every original cookie sent by the protected
server. In this new cookie an HMAC-SHA1 hash will be stored protecting
original cookie contents against malicious modification.

Url protection (and forced browsing):

Another point where web applications are vulnerable is concerning url format.
Indeed many applications use url parameter passing to communicate and
transmit information. In those scenarios, malicious url modifications can
lead a clever attacker to crash,abuse or exploit the application. This
situations can result in information leaks, impersonation, etc...  To
increase mod_security capabilities, new directives have been added to enable
url encryption. Using this feature original url's are replaced by encrypted
ones  making client browsing totally opaque. This mechanism provides not only
hidding of  actual url components, but also enables a method to avoid url
tampering.In case  any modifications is done over the encrypted url,
mod_security will fail to decrypt it and then silently discard it taking the
configured default error action.

With the aim of making this new functionalities more flexible and useful,
supplied directives allow user to define when and where to apply this crypto
protection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches that
pattern will be identified as an entry point, and then will get protected
using encryption.

As done with cookies, there has been also provided a "softer" method to
protect links. Instead of Encrypting the url, user is capable of defining
Hashed entry points. When this mode is selected, for each uri processed that
match an entry point  pattern an HMAC-SHA1 hash is generated and added to it.
Then whenever a request is received containing this seal value, mod security
will recalculate the hash corresponding to received uri , checking it against
original assigned hash seal.

If it has been tampered, hash would not be equal to the provided originally
and  that would cause mod_security to reject the request.

Crypto Notes:

Both previously described facilities rely on simmetric key cryptography. That
is why it is so important to select good crypto keys, and change them often
in order to  reduce the time window for a brute force attack. To this end,
this patch supplies a built-in capability to generate crypto keys, and
provides a way to configure key validity period to customize it to suit any
scenario. (so is to say, setting short periods for high traffic sites, or
long ones for sites with less request ratio).


REQUIREMENTS:

* CRYPTLIB:

Encryption enhancements rely on routines provided by cryptlib, so in order  to
be able to build the module, a proper installation of cryptlib is needed. As
a rule of thumb it should work whether you use a shared library supplied by
your preferred distribution, or you may deploy your own installation.

For downloads and further information:
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

* LIBXML2:
Html parsing is built on top of libxml2 tools, so you need to have it
installed on your system. Again you can use your distribution library package
or you may install it from sources:

For downloads and further information:
http://xmlsoft.org/downloads.html

* APACHE HTTP SERVER And LIBAPR (sources or at least development headers)

As this in the end is an apache-httpd module, you'll need a suitable build
environment, being it provided by your distribution apache-devel packages or
supplied by a raw installation from upstream sources.

For downloads and further information:
http://httpd.apache.org/

IMPORTANT NOTE: This patch is provided only against mod_security for apache
2.0,
        there is no provided code for mod_security for apache 1.3. Any way as we're
supplying the code, the door is wide open to anyone willing contribute and
backport this code to work with apache 1.3.

INSTALLATION:
1 - Get a fresh copy of modsecurity version 1.9.4
        wget http://www.modsecurity.org/download/modsecurity-apache_1.9.4.tar.gz

2 - Extract it
        tar -xvzf /modsecurity-apache_1.9.4.tar.gz

3 - Apply patch
        cd modsecurity-apache_1.9.4
        bzcat path/to/crypto- patch-0.01-for-modsecurity_1.9.4.diff.bz2 | patch -p1

4 - Edit Makefile :

* Configure headers an library paths according to apache
http server settings on your site:

top_dir         = /path/to/installed/apache- 2.0.XX
top_srcdir      = /path/to/sources/apache- 2.0.XX
top_builddir    = ${top_srcdir}

* If you're using libraries outside of standard locations yo may need to
configure also cryptlib and libxml paths (if they are not propperly resolved
by your environment settings):

cryptlib_srcdir = /path/to/cryptlib/sources
libxml2_srcdir  = /path/to/libxml/sources

5 - Run make, make install.

6 - If no errors are issued, you're ready to start using crypto enhancements.
To do so you must enable and configure them in your httpd.conf file.
(obviously you must add a LoadModule directive for mod_security)

Related keywords are:

        -SecCryptoEngine [ On | Off ]
                To enable disable Encryption Engine.
                example:
                        SecCryptoEngine On

        -SecCryptoCookies [ CookieSeal | CookieEncrypt ] ["default_actionset"]
                To enable cookie protection:
                        When Using CookieSeal, issued cookies will be protected with a new
                        generated cookie seal. Both cookies are sent to client browser so
                        applications that access them at client side are able to do so. When new
                        requests are made, received cookies at server side are checked against its
                        corresponding seal to prevent cookie tampering. In case received cookies
                        are found corrupt, they Are transparently suppressed and default actionset
                        is taken if defined (global error default actionset is assumed if no                            i
                        actionset is provided) .
                        example:
                                SecCryptoCookies CookieSeal "log,redirect: http://www.example.com "

                        When using CookieEncrypt mode, cookies issued by protected app are replaced
                        with encrypted ones which hold the same information. In this mode
                        application can't access cookies at client side (because they're ncrypted).
                        When in subsequent requests they're sent back to the server, mod_security
                        will seamlessly decrypt them rebuilding the original cookie contents to
                        deliver it to the sender app. As in the previous mode, application is
                        protected because any received cookie which fails to be decrypted, is
                        immediately removed causing request to be treated as specified in actionset
                        parameter (or global default actionset if none is supplied).

                        example:
                                SecCryptoCookies CookieEncrypt "log,redirect:http://www.example.com"

    -SecCryptoLinksEntryPoint [LinkHash | LinkEncrypt] "regular_expression"
                        To enable link protection by defining an entry point. This configuration
                        implies that any outgoing served page will be scanned in order to spot
                        instances of links that match the given pattern (regular expression). Those
                        items found will be treated as entry points and will get processed
                        according to specified mode.

                        If encription is choosen, link will be replaced by refurbished uri formated
                        like this:


http://www.example.com/SEC_DATA/<chunk_of_data_corresponding_to_encrypted_original_link>

                        When in subsequent client activity this request is issued back to the
                        server, mod_security will seamlessly decrypt this uri rebuilding the
                        original one that will be then sent to the the backend server. If any
                        modification has been done to the url, it will fail to decrypt causing
                        mod_security to discard it and take global default action or customized
                        particular action defined by SecCryptoEncryptedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkEncrypt "/path/to/site/administration"

                        If sealing is choosen, link will be replaced by refurbished where a
                        new "security seal" has been added : (uri will be formated like this)


http://www.example.com/path/to/file.html?SEC_DATA=<HMAC_SHA1_HASH_of_original_link>

                        When in later client petitions this request is issued back to the server,
                        mod_security will seamlessly recalculate hash for provided uri matching it
                        against SEC_DATA parameter. If any modification has been done to the url,
                        it will fail to match the seal causing mod_security to discard it and take
                        global default action or customized particular action defined by
                        SecCryptoHashedLinksDefaultAction.

                        example:
                                SecCryptoLinksEntryPoint  LinkHash "/path/to/site/shopping-cart"

    -SecCryptoEncryptedLinksDefaultAction "default actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but is not
                itself encrypted.

                example:
                        SecCryptoEncryptedLinksDefaultAction "log,redirect: http://www.example.com"

    - SecCryptoHashedLinksDefaultAction "default_actionset"
                To define actions to take whenever an error occurs processing incoming
                requests that contain an uri that match a defined entry point but uri do not
                match provided seal.

                example:
                        SecCryptoHashedLinksDefaultAction "log,redirect: http://www.example.com"

    - SecCryptoEncryptKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                encryption ). By default mod_security is set to renew encryption keys every
                600 seconds.

                example:
                        SecCryptoEncryptKeyRenewalPeriod 300

    - SecCryptoHashKeyRenewalPeriod
                To define how long (in seconds) a Key will be valid ( used for
                HMAC-SH1 hashing ). By default mod_security is set to renew encryption keys
                every 600 seconds.

                example:
                        SecCryptoHashKeyRenewalPeriod 300



Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642


_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users





Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


 
 

How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
mod-security-users mailing list
mod-security-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-users
Ivan Ristic | 10 Jul 09:51 2006
Picon

Re: Contributed patch adding crypto features [Forrester evaluation of web application firewalls]

On 7/7/06, Daniel Fdez. Bleda <dfernandez <at> isecauditors.com> wrote:
>
> Provided patch applies to ModSecurity version 1.9.4, enhancing
> ModSecurity to be able to apply cryptography to its web application
> firewall tasks.
>
>    - Cookie protection:
>    - URL protection (and forced browsing):

Daniel & Carles,

Many thanks for your efforts! Incorporating your work into ModSecurity
is on the top of my list for the next stable release (the one that
comes after 2.0).

--

-- 
Ivan Ristic, Technical Director
Thinking Stone, http://www.thinkingstone.com
ModSecurity: Open source Web Application Firewall

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Gmane