Inputs on ModSecurity and JavaScript?

Thanks for the time to give some inputs. I think my second-to-the-last sentence created more confusion. Indeed the obfuscation does nothing much in terms of hiding the code especially if it's already in the browser. I will take it out to make the answers more focused on what I'm really more concerned about. It's more about mitigating the HTTP POST DoS attack. It can be found here -

http://www.esecurityplanet.com/trends/article.php/3921156/Denial-of-Service-A....

There are already mitigating techniques in place. But I'm trying to put in another layer of prevention using the open source Apache module called ModSecurity and use its content injection capability to detect if client requests are coming from legitimate clients like browsers and not tools often used for DoS attacks. I assumed that most legitimate web clients would have the complete browser technology stack would have JavaScript. I tested this against slowhttptest from Qualys found here -

https://community.qualys.com/blogs/securitylabs/2011/08/25/new-open-source-to...

and

the OWASP tool found here - https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool

So far the results are effective and even performed better than the ones from the first article. Using the above mitigation forces potential attackers to check why his connections are dropped. If he figures out that cookies are used by the firewall to kick him out he will try to grab cookies given out by a server. If he used CURL or some programming language, he will fail. If he used a browser first, then he can succeed immediately because the JavaScript cookie will be included.

However given that I don't know JavaScript that much, I'm just not sure how easy it is to create a POC tool that can run JavaScript from a webpage, generate the additional cookies, grab the cookies from that page and use it to run a denial of service attack against the server.

I also read somewhere that JavaScript can run outside the browser. It can be used in ActionScript, Flash, AIR, and can be used for desktop applications. But can it be theoretically used to create a tool that can trigger and grab cookies to use these on an HTTP POST DoS attack?

Thanks and really appreciate the inputs.

You are taking the wrong approach to the problem. From your first link:
===========
Brennan explained that a layer 7 DoS occurs when a client comes to a web server and makes a connection request such as a form field via an HTTP POST request. The web server waits for the form field request data, which is sent by the attack at a very slow rate.

"What if I was able to have one machine create 20,000 plus connections to the web server and send a really slow form request," Brennan said. "What I'm doing is a Denial of Service that is going to make the web server unavailable to legitimate clients."
===========
It is not normal for one client to make 20000 requests to a server. By the 100th connection, the web esrver should be terminating the connections as bogus, or an error, not just sitting there.

This attack needs defending with new code in the web server where HTTP POST requests are handled. It needs to count HHTP POST requests from each host, and terminate them all if they exceed a pre-definied count (e.g. 20). It would obviously need tailoring per web application, but by stopping the server from sitting there in the first place, the DoS is mitigated.

I mean simultaneous connections.

Thanks. But already have that defense in place. Used SecWriteState Limit to drop connections if and IP address went beyond a number of connections in SERVER_BUSY_WRITE state. Also used another protection using a timeout whenever the request bodies reached a certain limit then triggered a block for N minutes for that specific IP address whenever the rate of timeouts occurred more than X times in Y seconds. But I wanted to take it a step further by blocking all requests immediately not coming from a browser, like the tools used to normally do this type attack. That's why I explored it at another angle. But I'm just curious if JS is able to run these types of attacks, hence foiling the added mitigation.

But I wanted to

Hmm.... it seems that to exploit HTTP_POST the "client" already requires some form of connection to the web server. Spoofing this is trivial, and trying to use JS detection to do it is not the best way. What if a legitimate client has JS disabled? What will happen then?

Indeed. That is the biggest limitation. But according to another opinion I got, requiring the clients to enable JS is acceptable, and it is on by default anyway. At least all other requests are dropped. It defends well against the Slow GET and newest form of slow DoS attacks called Slow Read. So this limits the vulnerability to a tool that activates the JS cookie and performs any of the slow HTTP attacks.

The biggest limitation is the client already needing a connection to the server? Did I understand correctly?

If you put the detection in the web server itself, no external tools are required, and you don;t have to load up my connection with extraneous JS, and better yet, you eliminate the client completely from the solution.

The best fix here is to do it in the web server. It can even look to see how fast the throughput is, and cut off anyone not meeting a minimum (e.g. 5 kB/sec).

Well, actually I was refering to enabling JS. As I said, I already have mitigations regarding meeting a certain minimum rate using timeouts and checking if the client has too many connections. My challenge is detecting if the request is coming from a browser, then cut off all connections identified to be non-browsers. Hence, using JS. Then maybe flash or any other browser based technology. So far JS is the easiest to inject so I made use of this.

You're taking entirely the wrong approach. You can NOT, *EVER*, use a client you do not totally control as part of a security solution. An attacker can be the browser, they can spoof it, and control it. Your solution must be entirely server based, using checks I described earlier, looking for behaviors a legitimate client will not make.

Your solution may work today, but if the assets it is meant to be protecting are worth the trouble, an attacker will defeat it, and quite easily at that.

Why use Flash?? You are again assuming the client has that technology. What if they connect from a mobile device? Apple doesn't support Flash. You are also loading up not only the remote connection with junk, but are now loading the browser and remote computer with additional processing tasks, that will do nothing for security.

You may think I'm being difficult, but fixing the web server directly is the ONLY way to go. Of course, this attack will not affect only your servers, but everyone, unless HTTP_POST is prohibited. Your solution is frankly ridiculous.

The more complex you make your solution, the more likely it is to become a security threat in its own right. Simplicity rules, and in this case, fixing the web server itself is the only viable option.