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.

As Ivan explained, those functionalities refer to the use ofcryptography 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 securityassessment, we've found some areas concerning web application securitythat lacked some a reliable protection mechanism. For that reason and
being ModSecurity an amazing base tool, we decided to improve it byextending it to suit our needs to provide better services to ourcustomers.

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 availableto 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 ModSecurityusers do a some beta testing and report problems that eventually willemerge (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 strongcryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, butnot 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, thisfunctionalities to be added in next major release (hopefully in
2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancingModSecurity to be able to apply cryptography to its web applicationfirewall 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.

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 muchtested so your mileage will vary.This initial release is not intendedfor production systems, but only for testing purposes.

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

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

Anyway, we are working in more features and looking forward tocontribute 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 newfeatures to be added will be greatly appreciated and for sure be studied.

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

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 theterms of the GNU General Public License as published by the Free SoftwareFoundation; 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 WITHOUTANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESSFOR 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 highunstable 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 toModSecurity community hoping this will be useful to anyone who may bewilling 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 webapplication 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', istransferred 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 availablein future connections.

Being this mechanism used by web applications to gather and manage clientsession information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by serverside and stored by the client. Then within normal client-servercommunication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by theclient in his subsequent requests is trusted as far as it's consideredgenerated 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 tomodify cookie content trying to alter normal server application response intohis benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is atask left to server web applications. So this security aspect completelyrelies 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 tobe correct.

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

The goal of this patch is enhance mod_security by adding functionalities toprotect web applications that use cookies as state management mechanismagainst cookie modification (a.k.a
poisoning or tampering). This protectionis done by cryptography means. To achieve this several new configurationdirectives 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 AESalgorithm 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 itthis way, those applications will not need to be aware of thiscountermeasures (so no modification/adaptation needed to run'behind' modsecurity). Due to this, if a web application needs client-side access to
cookie stored values, this encryption method will cause it to stop workingbecause cookies at the browser side will be stored in encrypted format. Toovercome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security willissue a new seal cookie for every original cookie sent by the protectedserver. 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 canlead a clever attacker to crash,abuse or exploit the application. Thissituations can result in information leaks, impersonation, etc... To
increase mod_security capabilities, new directives have been added to enableurl encryption. Using this feature original url's are replaced by encryptedones making client browsing totally opaque. This mechanism provides not only
hidding of actual url components, but also enables a method to avoid urltampering.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 cryptoprotection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches thatpattern will be identified as an entry point, and then will get protectedusing 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 definingHashed entry points. When this mode is selected, for each uri processed thatmatch 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 securitywill recalculate the hash corresponding to received uri , checking it againstoriginal 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. Thatis 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, andprovides 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, orlong 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. Asa rule of thumb it should work whether you use a shared library supplied byyour preferred distribution, or you may deploy your own installation.

* 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 buildenvironment, being it provided by your distribution apache-devel packages or
supplied by a raw installation from upstream sources.

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'resupplying the code, the door is wide open to anyone willing contribute andbackport this code to work with apache 1.3.

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)

-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).

-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:

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.

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.

-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.

- 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.

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.

As Ivan explained, those functionalities refer to the use ofcryptography 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 securityassessment, we've found some areas concerning web application securitythat lacked some a reliable protection mechanism. For that reason and being ModSecurity
an amazing base tool, we decided to improve it byextending it to suit our needs to provide better services to ourcustomers.

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 availableto 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 ModSecurityusers do a some beta testing and report problems that eventually willemerge (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 strongcryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, butnot 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, thisfunctionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancingModSecurity to be able to apply cryptography to its web applicationfirewall 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.

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 muchtested so your mileage will vary.This initial release is not intendedfor production systems, but only for testing purposes.

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

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

Anyway, we are working in more features and looking forward tocontribute 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 newfeatures to be added will be greatly appreciated and for sure be studied.

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

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 theterms of the GNU General Public License as published by the Free SoftwareFoundation; 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 WITHOUTANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESSFOR 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 highunstable 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 toModSecurity community hoping this will be useful to anyone who may bewilling 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 webapplication 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', istransferred 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 availablein
future connections.

Being this mechanism used by web applications to gather and manage clientsession information, cookies became a central point when security is concerned. Conforming to the standard, cookie info is generated by serverside and stored by the client. Then within normal client-servercommunication, client is supposed to send suitable cookies based upon defined criteria. From the server point of view, cookie information retrieved by theclient in his subsequent requests is trusted as far as it's consideredgenerated 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 tomodify cookie content trying to alter normal server application response intohis benefit leading this situation to a session hijack or an information leak.

As far as cookie management standard,
information integrity and privacy is atask left to server web applications. So this security aspect completelyrelies 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 tobe correct.

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

The goal of this patch is enhance mod_security by adding functionalities toprotect web applications that use cookies as state management mechanismagainst cookie modification (a.k.a poisoning or tampering). This protectionis done by cryptography means. To achieve this several new configurationdirectives 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 AESalgorithm using a private user defined encryption KEY.

An important aspect to take into account is that this protection is intendedto be as much transparent as possible to protected applications. Doing itthis way, those applications will not need to be aware of thiscountermeasures (so no modification/adaptation needed to run'behind' modsecurity). Due to this, if a web application needs client-side access to cookie stored values, this encryption method will cause it to stop workingbecause cookies at the browser side will be stored in encrypted format. Toovercome this issue, another cookie protection mode has been provided. The alternative is use cookie sealing. When using this setting, mod_security willissue a new seal cookie for every original cookie sent by the protectedserver. 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 canlead a clever attacker to crash,abuse or exploit the application. Thissituations can result in information leaks, impersonation, etc... To increase mod_security capabilities, new directives have been added to enableurl encryption. Using this feature original url's are replaced by encryptedones making client browsing totally opaque. This mechanism provides not only hidding of actual url components, but also enables a method to avoid urltampering.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 cryptoprotection by means of declaring entry_points. An entry point is defined using a regular expression. Based upon that, any link that matches thatpattern will be identified as an entry point, and then will get protectedusing 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 definingHashed entry points. When this mode is selected, for each uri processed thatmatch 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 securitywill recalculate the hash corresponding to received uri , checking it againstoriginal 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. Thatis 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, andprovides 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, orlong 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. Asa rule of thumb it should work whether you use a
shared library supplied byyour preferred distribution, or you may deploy your own installation.

* 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 buildenvironment, being it provided by your distribution apache-devel packages or supplied by a raw installation from upstream sources.

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'resupplying the code, the door is wide open to anyone willing contribute andbackport this code to work with apache 1.3.

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)

-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).

-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:

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.

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.

-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.

- 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.

__________________________________________________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

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.

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 :)

As Ivan explained, those functionalities refer to the use ofcryptography 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 securityassessment, 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 byextending it to suit our needs to provide better services to ourcustomers.

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 ModSecurityusers 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 strongcryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, butnot 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, thisfunctionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version
1.9.4, enhancingModSecurity to be able to apply cryptography to its web applicationfirewall 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.

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 muchtested 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 fullsourcecode tarball for the crypto empowered ModSecurity and also apackage containing source documentation code generated with doxygen.

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

Anyway, we are working in more features and looking forward tocontribute 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 newfeatures to be added will be greatly appreciated and for sure be studied.

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

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 theterms 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 WITHOUTANY 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 toModSecurity 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 webapplication 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', istransferred 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 availablein future connections.

Being this mechanism used by web applications to gather and manage clientsession information, cookies became a central point when security is
concerned. Conforming to the standard, cookie info is generated by serverside and stored by the client. Then within normal client-servercommunication, client is supposed to send suitable cookies based upon defined
criteria. From the server point of view, cookie information retrieved by theclient in his subsequent requests is trusted as far as it's consideredgenerated 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 tomodify cookie content trying to alter normal server application response intohis benefit leading this situation to a session hijack or an information
leak.

As far as cookie management standard, information integrity and privacy is atask left to server web applications. So this security aspect completelyrelies 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 tobe correct.

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

The goal of this patch is enhance mod_security by adding functionalities toprotect web applications that use cookies as state management mechanismagainst cookie modification (a.k.a
poisoning or tampering). This protectionis done by cryptography means. To achieve this several new configurationdirectives 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 AESalgorithm 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 itthis way, those applications will not need to be aware of thiscountermeasures (so no modification/adaptation needed to run'behind' modsecurity). Due to this, if a web application needs client-side access to
cookie stored values, this encryption method will cause it to stop workingbecause cookies at the browser side will be stored in encrypted format. Toovercome this issue, another cookie protection mode has been provided. The
alternative is use cookie sealing. When using this setting, mod_security willissue a new seal cookie for every original cookie sent by the protectedserver. 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 canlead a clever attacker to crash,abuse or exploit the application. Thissituations can result in information leaks, impersonation, etc... To
increase mod_security capabilities, new directives have been added to enableurl encryption. Using this feature original url's are replaced by encryptedones making client browsing totally opaque. This mechanism provides not only
hidding of actual url components, but also enables a method to avoid urltampering.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 cryptoprotection by means of declaring entry_points. An entry point is defined
using a regular expression. Based upon that, any link that matches thatpattern will be identified as an entry point, and then will get protectedusing 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 definingHashed entry points. When this mode is selected, for each uri processed thatmatch 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 securitywill recalculate the hash corresponding to received uri , checking it againstoriginal 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. Thatis 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, andprovides 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, orlong 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. Asa rule of thumb it should work whether you use a shared library supplied byyour preferred distribution, or you may deploy your own installation.

* 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 buildenvironment, being it provided by your distribution apache-devel packages or supplied by a raw installation from upstream sources.

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'resupplying the code, the door is wide open to anyone willing contribute andbackport this code to work with apache 1.3.

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)

-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).

-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:

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.

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.

-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.

- 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.

__________________________________________________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

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.

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 :)

As Ivan explained, those functionalities refer to the use ofcryptography 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 securityassessment, 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 byextending it to suit our needs to provide better services to ourcustomers.

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 ModSecurityusers 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 strongcryptography protection to their web applications.

Any feedback will be greatly appreciated (using this list is fine, butnot 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, thisfunctionalities to be added in next major release (hopefully in 2.1).

Provided patch applies to ModSecurity version 1.9.4, enhancingModSecurity to be able to apply cryptography to its web applicationfirewall 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.

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
muchtested 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 fullsourcecode tarball for the crypto empowered ModSecurity and also apackage containing source documentation code generated with doxygen.

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

Anyway, we are working in more features and looking forward tocontribute 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 newfeatures to be added will be greatly appreciated and for sure
be studied.

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

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 theterms 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 WITHOUTANY 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 toModSecurity 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 webapplication 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', istransferred 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 availablein future connections.

Being this mechanism used by web applications to gather and manage clientsession information, cookies became a central point when security is concerned. Conforming to the standard, cookie info is generated by serverside and stored by the client. Then within normal client-servercommunication, client is supposed to send suitable cookies based upon defined criteria. From the server point of view, cookie information retrieved by theclient in his subsequent requests is trusted as far as it's consideredgenerated 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 tomodify cookie content trying to alter normal server application response intohis benefit leading this situation to a session hijack or an information leak.

As far as cookie management standard, information integrity and privacy is atask left to server web applications. So this security aspect completelyrelies 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 tobe correct.

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

The goal of this patch is enhance mod_security by adding functionalities toprotect web applications that use
cookies as state management mechanismagainst cookie modification (a.k.a poisoning or tampering). This protectionis done by cryptography means. To achieve this several new configurationdirectives 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 AESalgorithm using a private user defined encryption KEY.

An important aspect to take into account is that this protection is intendedto be as much transparent as possible to protected applications. Doing itthis way, those applications will not need to be aware of thiscountermeasures (so no modification/adaptation needed to run'behind' modsecurity). Due to this, if a web application needs client-side access to cookie stored values, this encryption method will cause it to stop
workingbecause cookies at the browser side will be stored in encrypted format. Toovercome this issue, another cookie protection mode has been provided. The alternative is use cookie sealing. When using this setting, mod_security willissue a new seal cookie for every original cookie sent by the protectedserver. 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 canlead a clever attacker to crash,abuse or exploit the application. Thissituations can result in information leaks, impersonation, etc... To increase mod_security capabilities, new directives have been added to
enableurl encryption. Using this feature original url's are replaced by encryptedones making client browsing totally opaque. This mechanism provides not only hidding of actual url components, but also enables a method to avoid urltampering.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 cryptoprotection by means of declaring entry_points. An entry point is defined using a regular expression. Based upon that, any link that matches thatpattern will be identified as an entry point, and then will get protectedusing 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 definingHashed entry points. When this mode is selected, for each uri processed thatmatch 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 securitywill recalculate the hash corresponding to received uri , checking it againstoriginal 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. Thatis 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, andprovides 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, orlong 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. Asa rule of thumb it should work whether you use a shared library supplied byyour preferred distribution, or you may deploy your own installation.

* 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 buildenvironment, being it provided by your distribution apache-devel packages or supplied by a raw installation from upstream sources.

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'resupplying the code, the door is wide open to anyone willing contribute andbackport this code to work with
apache 1.3.

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)

-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).

-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:

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.

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.

-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.

- 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.

-------------------------------------------------------------------------
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