Redirect-Location for nx_tools/intercept

[GoogleCodeExporter]

i'd like to be able to issue a redirect-locatiion for nx_intercept to be able 
to first catch the event and then redirect the user onto a given location.

background: i have a naxsi-installation infront of a very ugly cms and a lot of 
cookie-abuse; besid just session-infos the devs store a bunch of stuff in 
cookies AND url/args that triggers nearly every rule from the coreset (> 80.000 
false positives a day). the cms is musltisite and multidomain and its nearly 
impossible to have that for a testdrive with naxsi in learning mode, but i 
managed to get the alerts to nearly no fps any more with heavy whitelisting.
but sinde i dont know what the devs will implement next i'd like to have a 
possibility to redirect users, instead of blocking them whit a white page. but 
i still want to store the alerts into the database, this need nx_util/intercept

Original issue reported on code.google.com by lazy.dog...@gmail.com on 12 Mar 2013 at 8:57

[GoogleCodeExporter]

Hey mex :)

I'm not 100% sure I understood you, but you could give a try to post action.
It's something that is called upon request completion (and naxsi already uses 
that in learning mode), like :

location /Denied {
 proxy_pass http://your_server_that_returns_stuff:8080;
 post_action /NxIntercept;
}

location /NxIntercept {
 proxy_pass http://nx_intercept:8080;
}

But please remind, we are going to kill nx_intercept/live learning !
If you have a problem with that (killing live learning), please let me know ;)

Original comment by ori...@gmail.com on 13 Mar 2013 at 8:54

[GoogleCodeExporter]

either this or

location /RequestDenied {
  proxy_pass http://nx_intercept:8080;
}

in in naxsi-ui.conf

redirect_location = "/why-you-came-here"

Original comment by lazy.dog...@gmail.com on 13 Mar 2013 at 12:28

[GoogleCodeExporter]

Original comment by didier.c...@googlemail.com on 4 Apr 2013 at 1:53

• Changed state: New
• Added labels: Component-Logic, Type-Other

[GoogleCodeExporter]

i had a nice talk recently with some owasp - guys who told me that a timing - 
attack is possible if the waf simply drops the connection, thus allowing an 
attacker to determine which rules are loaded and which waf might be used. if we 
pass the intercepted request to a default error-page, handeled by the app, 
those  timing-attacks are more difficult.

see https://www.usenix.org/system/files/conference/woot12/woot12-final2.pdf

Original comment by lazy.dog...@gmail.com on 10 Apr 2013 at 10:27

Attachments:

• woot12-final2.pdf