Ulisses,

I think something like:

SecRule JSON "@rx test" "..."    <- This will loop and execute operation against all JSON variable values
SecRule JSON:name "@rx test" "..."
SecRule JSON:user/phone "@rx 123456" "..."

SecRule JSON_RAW "@rx test" "..." -> an unique string with all json data.
SecRule JSON_NAMES "@rx [a-b] "..."-> collection with variable names

Let see what Ryan think about it from rule creation point of view.

Thanks

Breno

On Sun, Sep 23, 2012 at 1:54 PM, Ulisses Montenegro <ulisses.montenegro@gmail.com> wrote:
Breno,

Perhaps it would be easier to look at this the order way around --
what would be the most flexible way to write rules for matching JSON
data? From a parsing perspective, most libraries offer a
JSON-string-to-hashtable approach, which would work for all either
scenario.

Ryan, do you have any real world use cases for rules matching JSON parameters?

Thanks!

On Sun, Sep 23, 2012 at 3:38 PM, Breno Silva <breno.silva@gmail.com> wrote:
> Ulisses,
>
> I never had a change to think more about this issue.
> Looking for this specific case i really don't think would be a good idea to
> create a new logic to ARGS* collections. Not sure what Ryan B. think about
> it, but from my point of view, if we need a new logic we must create
> specific collections.
>
> ie:  JSON,  JSON_NAMES ....
>
> Is "." (dot)  allowed to create variables names ? I think yes.
> If so, we should go json specification and find a better way to create this
> logic.  Maybe using "/" ?
>
> ie: user/name, user/manager/name
>
> What do you think ?
>
> Breno
>
> On Sun, Sep 23, 2012 at 12:34 PM, Ulisses Montenegro
> <ulisses.montenegro@gmail.com> wrote:
>>
>> Breno & Ryan
>>
>> Thanks for the pointers. Ryan, I need to look further into how ARGS
>> could be used to handle nested data structures. Although deeper
>> structures are more common in responses, I've seen some in requests
>> too. If we go deeper then 2 levels, then how would we break that data
>> into ARGS?
>>
>> { 'user': {
>>     'name': 'John Doe',
>>     'email': 'johndoe@domain.com',
>>     'manager': {
>>         'name': 'Manager John',
>>         'email': 'manager@domain.com',
>>         'company': {
>>             'name': 'ModSecurity Corp.',
>>             (...)
>>         },
>>     }
>> }
>>
>> I was thinking that maybe using the fully qualified name for the
>> variable might be easier, and would not introduce any artificial
>> limitations on the depth on the data structure in the JSON data:
>>
>> ARGS:user.name = 'John Doe'
>> ARGS:user.email = 'johndoe@domain.com'
>> ARGS:user.manager.name = 'Manager John'
>> ARGS:user.manager.company.name = 'ModSecurity Corp.'
>> (...)
>>
>> Of course, JSON also supports arrays, but since mod_security already
>> handles multiple instances of the same parameter, that would not be an
>> issue for either option.
>>
>> Does that make sense, or am I misunderstanding how ARGS work?
>>
>> Thanks,
>> Ulisses
>>
>> On Sun, Sep 23, 2012 at 1:46 PM, Ryan Barnett <RBarnett@trustwave.com>
>> wrote:
>> > Regarding #2 below - we have two options.
>> >
>> > 1) A JSON parse could work like the XML parse and access the request
>> > body
>> > content and simply populate a new collection called JSON.  This is like
>> > the XML collection that is simply a long string of text.  The downside
>> > of
>> > this approach is that here is no context as to what are parameter
>> > names/values.  Another option would be to have the JSON parser simply
>> > populate this string of text into the current REQUEST_BODY variable.  A
>> > rule writer can do this today if they wish using the following example
>> > pseudo-rule -
>> >
>> > SecRule REQUEST_HEADERS:Content-Type "@contains application/json"
>> > "phase:1,id:1,nolog,pass,ctl:forceRequestBodyVariable"
>> >
>> > 2) I think that the best way to do this is to attempt to parse the JSON
>> > data into name/value pairs and populate that into ARGS.  If it is parsed
>> > in this way, then we don't need to change anything in the current rules.
>> >
>> > As just one example, I was reviewing the JSON data sent back to twitter
>> > in
>> > response to a Content Security Policy (CSP) violation.  The content-type
>> > is application/json and uses the name/value pairs -
>> >
>> > POST /scribes/csp_report HTTP/1.1
>> > Host: twitter.com
>> > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0)
>> > Gecko/20100101 Firefox/15.0
>> > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>> > Accept-Language: en-us,en;q=0.5
>> > Accept-Encoding: gzip, deflate
>> > DNT: 1
>> > Connection: keep-alive
>> > Content-Length: 338
>> > Content-Type: application/json
>> >
>> >
>> > {"csp-report":{"document-uri":"https://mobile.twitter.com/i/templates/m5?re
>> >
>> > v=1347385509950","referrer":"https://mobile.twitter.com/","blocked-uri":"se
>> > lf","violated-directive":"inline
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22referrer
>> >
>> > %22:%22https://mobile.twitter.com/%22,%22blocked-uri%22:%22self%22,%22viola
>> > ted-directive%22:%22inline> script base
>> >
>> > restriction","source-file":"https://mobile.twitter.com/i/templates/m5?rev=1
>> > 347385509950","script-sample":"onclick
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22script-s
>> > ample%22:%22onclick> attribute on DIV element"}}
>> >
>> > Based on this ­ you would split the name/value pairs by the "Š":"Š."
>> > format and have parsed ARGS variable data for use in our rules like -
>> >
>> > ######################
>> > ARGS:csp-report =
>> >
>> > "document-uri":"https://mobile.twitter.com/i/templates/m5?rev=1347385509950
>> >
>> > ","referrer":"https://mobile.twitter.com/","blocked-uri":"self","violated-d
>> > irective":"inline
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22referrer
>> >
>> > %22:%22https://mobile.twitter.com/%22,%22blocked-uri%22:%22self%22,%22viola
>> > ted-directive%22:%22inline> script base
>> >
>> > restriction","source-file":"https://mobile.twitter.com/i/templates/m5?rev=1
>> > 347385509950","script-sample":"onclick
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22script-s
>> > ample%22:%22onclick> attribute on DIV element"
>> >
>> > ARGS:document-uri =
>> > https://mobile.twitter.com/i/templates/m5?rev=1347385509950
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22referrer
>> >
>> > %22:%22https://mobile.twitter.com/%22,%22blocked-uri%22:%22self%22,%22viola
>> > ted-directive%22:%22inline>
>> >
>> > ARGS:referrer = https://mobile.twitter.com/
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22referrer
>> >
>> > %22:%22https://mobile.twitter.com/%22,%22blocked-uri%22:%22self%22,%22viola
>> > ted-directive%22:%22inline>
>> >
>> > ARGS:blocked-uri = self
>> >
>> > ARGS:violated-directive = inline script base restriction
>> >
>> > ARGS:source-file =
>> > https://mobile.twitter.com/i/templates/m5?rev=1347385509950
>> >
>> > <https://mobile.twitter.com/i/templates/m5?rev=1347385509950%22,%22script-s
>> > ample%22:%22onclick>
>> >
>> > ARGS:script-sample = onclick attribute on DIV element
>> > #######################
>> >
>> > Hope this helps.
>> >
>> >
>> > --
>> > Ryan Barnett
>> > Trustwave SpiderLabs
>> > ModSecurity Project Leader
>> > OWASP ModSecurity CRS Project Leader
>> >
>> >
>> >
>> >
>> >
>> > On 9/23/12 9:31 AM, "Ulisses Montenegro" <ulisses.montenegro@gmail.com>
>> > wrote:
>> >
>> >>Team
>> >>
>> >>As my first attempt in contributing to mod_security I've decided to
>> >>tackle MODSEC-253, a JSON body processor. I've gone through the XML
>> >>and multipart body processors and found them apparently
>> >>straightforward. I would like some pointers on issues which I need to
>> >>address before deciding on my solution, though.
>> >>
>> >>1. The XML body processor uses libxml for the actual XML parsing, I
>> >>assume adding a JSON parser library would be acceptable as well. If
>> >>so, what licenses would be acceptable?
>> >>2. XML processor offers a XPath interface for rules to match XML
>> >>contents, which is a standard, but AFAIK there is nothing equivalent
>> >>for JSON (aside from evaluating Javascript object references). What
>> >>interface would work best for the rules to gain access to the JSON
>> >>contents?
>> >>3. Are there any guidelines/rules regarding memory usage and
>> >>performance, i.e., how can if my code or the library I'm using is
>> >>performing acceptably? I know I can always benchmark/profile other
>> >>body processors and compare the results directly, but I'm looking more
>> >>towards hard numbers, if they're available.
>> >>4. Finally, do these kind of questions go into JIRA? I decided to try
>> >>the mailing list first as I did not want to add possibly irrelevant
>> >>information to the JIRA issue, but I think at least items [1] and [2]
>> >>should be registered there -- is that how it usually works?
>> >>
>> >>Thanks a lot for the great work on mod_security
>> >>Ulisses
>> >>
>> >>--
>> >>³If debugging is the process of removing software bugs, then
>> >>programming must be the process of putting them in.² - Edsger Dijkstra
>> >>
>>
>> >> >>--------------------------------------------------------------------------
>> >>----
>> >>Everyone hates slow websites. So do we.
>> >>Make your web apps faster with AppDynamics
>> >>Download AppDynamics Lite for free today:
>> >>http://ad.doubleclick.net/clk;258768047;13503038;j?
>> >>http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> >>_______________________________________________
>> >>mod-security-developers mailing list
>> >>mod-security-developers@lists.sourceforge.net
>> >>https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> >>ModSecurity Services from Trustwave's SpiderLabs:
>> >>https://www.trustwave.com/spiderLabs.php
>> >
>> >
>> > ________________________________
>> >
>> > This transmission may contain information that is privileged,
>> > confidential, and/or exempt from disclosure under applicable law. If you are
>> > not the intended recipient, you are hereby notified that any disclosure,
>> > copying, distribution, or use of the information contained herein (including
>> > any reliance thereon) is STRICTLY PROHIBITED. If you received this
>> > transmission in error, please immediately contact the sender and destroy the
>> > material in its entirety, whether in electronic or hard copy format.
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Everyone hates slow websites. So do we.
>> > Make your web apps faster with AppDynamics
>> > Download AppDynamics Lite for free today:
>> > http://ad.doubleclick.net/clk;258768047;13503038;j?
>> > http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> > _______________________________________________
>> > mod-security-developers mailing list
>> > mod-security-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> > ModSecurity Services from Trustwave's SpiderLabs:
>> > https://www.trustwave.com/spiderLabs.php
>>
>>
>>
>> --
>> “If debugging is the process of removing software bugs, then
>> programming must be the process of putting them in.” - Edsger Dijkstra
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> mod-security-developers mailing list
>> mod-security-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> mod-security-developers mailing list
> mod-security-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mod-security-developers
> ModSecurity Services from Trustwave's SpiderLabs:
> https://www.trustwave.com/spiderLabs.php



--
“If debugging is the process of removing software bugs, then
programming must be the process of putting them in.” - Edsger Dijkstra

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
mod-security-developers mailing list
mod-security-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-security-developers
ModSecurity Services from Trustwave's SpiderLabs:
https://www.trustwave.com/spiderLabs.php