I've got a Drupal site with a custom user profiles page that allows users to enter URLs for their social sites like Twitter and Facebook. Because these form textfields can contain the string "http://" in them, when I try to save the user profile page I'm getting blocked (rules listed below). I've included the following in my user conf file for mod_security after the includes and it cancels out the 4 offending rules.

<LocationMatch "/">
SecRuleRemoveById 340162 #Generic PHP code injection protection in URI w/ anti-evasion
SecRuleRemoveById 340163 #Generic PHP code injection protection in URI w/ anti-evasion and multimatch
SecRuleRemoveById 340147 #Generic XSS filter
SecRuleRemoveById 340007 #Generic recursion signatures
</LocationMatch>

However, I'm worried that these rules are fairly generic and eliminating these rules outright is going to open the site up to attacks.
I'm not sure I understand the logic here though. If any form field with http:// in it gets blocked, what happens to blog posts with embedded HTML links?

Thanks!

Yeah, dont turn these off the way you have, thats a total global exclusion you've got there (and some of those rules are really important!).

Just tell us whats being blocked specifically, please use the process below to report false positives:

https://www.atomicorp.com/wiki/index.ph ... _Positives

And we will have a fix available the same day you report this issue.

Thanks for the reply! Well, I've only got one site on the server so it's probably not as bad as it could be but...

So I've clipped what I think is important from the audit log and censored out sensitive information from the post. So strangely, the first
&profile%5fwebsite1=http%3a%2f%2fwww%2ewebsitedomain%2ecom
doesn't cause a problem and will not 404. Only after I enter a 2nd entry, in this case, the next section of the string
&profile%5fpersonalblog=http%3a%2f%2fwww%2ewebsitedomain%2ecom
causes it to 404.

I hope this is the right information. By the way, if I rem out the 340162, then the following 3 kick in 340163, 340147, 340007 causing the same 404. Again, it works fine if I have a single field like website1 field filled in, but as soon as I add a second field, like personalblog, it 404's.

--8dbe1118-I--
name=username&mail=email%40emaildomain%2ecom&pass%5bpass1%5d=&pass%5bpass2%5d=&status=1&signature=%3cp%3e%0d%0a%09fdg+sfdg+fds+gfd+sgf+sgf+ds%3c%2fp%3e%0d%0a&signature%5fformat=1&profile%5fname=Webmaster&profile%5fbio=%3cp%3e%0d%0a%09g+fds+gfds+gfds+gf+sdgf+ds%3c%2fp%3e%0d%0a&profile%5frole%5fstaff=1&profile%5fwebsite1=http%3a%2f%2fwww%2ewebsitedomain%2ecom&profile%5fpersonalblog=http%3a%2f%2fwww%2ewebsitedomain%2ecom&profile%5ftwitter=&profile%5ffacebook=&profile%5flinkedin=&profile%5fpinkposse=&profile%5fphone=&profile%5faddress1=&profile%5faddress2=&profile%5fcity=&profile%5fstate=&profile%5fzip=&profile%5fcountry=&profile%5fbirthday%5bmonth%5d=6&profile%5fbirthday%5bday%5d=1&profile%5fbirthday%5byear%5d=2010&node%5fnotify%5fmailalert=1&comment%5fnotify%5fmailalert=1&timezone=%2d28800&xmlsitemap%5fuser%5fpriority=%2d2&form%5ftoken=00000000000000000000000000000000&form%5fbuild%5fid=form%2d00000000000000000000000000000000&form%5fid=user%5fprofile%5fform&op=Save&securelogin%5foriginal%5fbaseurl=http%3a%2f%2fwww%2ewebsitedomain%2ecom
--8dbe1118-F--
HTTP/1.1 404 Not Found
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Last-Modified: Mon, 28 Mar 2011 21:07:25 GMT
Cache-Control: store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

--8dbe1118-H--
Message: Access denied with code 403 (phase 2). Match of "beginsWith http://%{SERVER_NAME}/" against "MATCHED_VAR" required. [file "/usr/local/apache/conf/modsec_rules/10_asl_rules.conf"] [line "455"] [id "340162"] [rev "193"] [msg "Atomicorp.com - FREE UNSUPPORTED DELAYED FEED - WAF Rules: Remote File Injection attempt in ARGS (AE)"] [data "4125"] [severity "CRITICAL"]
Action: Intercepted (phase 2)
Stopwatch: 1301346445201088 633494 (7671* 15435 -)
Producer: ModSecurity for Apache/2.5.13 (http://www.modsecurity.org/).
Server: Apache

--8dbe1118-Z--

That issue was addressed in the real time rules a couple of months ago, so you'll see it updated soon in the free rules which are 90 days delayed from the real time rules. Or just upgrade to the realtime rules and you will have access to that now.

It sounds like you had some other issues, if you could provide the payloads for those as well we can help you with those as well.

Thanks for the reply. I'm glad to hear it was fixed. Too bad it will take some time for it to show up. I guess I'll leave the rule exclusions for now. The site hosting a single web page with trusted administrators, so I don't think there will be much of a security threat for now. I will suggest the client buy the subscription, but I don't think they will, at least not now.

Thanks again!

I changed the way my user profile worked by removing the http:// from the fields expecting that to work, but then ran into the same problem with any links embedded into my Bio textarea field. However I do not have the same problems with multiple links in Drupal node body fields (blog, page, etc). It's only happening AFAIK in my custom user profile fields and I'm not sure why.

I'm not sure I understand how this filtering rule works (and the gotroot rules in general). I'd like to better understand it so I can go in and make changes necessary to get this working. By reading through the rule, it looks like the rules block out specific exploits by directly blocking strings like index\.php\?url= in the URL or post arguments. Is this how it works (blacklist approach)? Because I do not see any specific strings that would block &bio=blahblahblah_http://www.site.com_blahblahblah_http://www.site.com and it shouldn't be triggering. If that's not correct and you're taking a more of a whitelist approach, I'm not understanding how that is defined. Are common Drupal node fields whitelisted somewhere I'm not finding? Is that why I can embed multiple links in the node body field but not in my custom profile fields?

Anyone point me in the right direction?

Thank you for the question. They don't work like that. The rules are written to address specific attack classes, vulnerability classes using negative rules, known vulnerabilities in specific applications using positive and negative rules, known trusted/safe behaviour for applications via positive rules (and a few negative rules) and known application weakness classes via positive rules. The rules are also designed to detect known malicious tools and clients, spam content, out of normal conditions for web applications, protocol violations and known blacklisted hosts as well as known malicious sources of malware and/or compromised systems currently being used to compromise other system, or hosting malicious software that is being used to compromise systems.

ASL makes it possible to define these via the rule manager should you need to, and for real time customers all they have to do is a report a false positive to us and we will fix the rules the same day for free.

Without the actual payloads its not really possible to answer your question about tuning the rules for your needs or addressing a false positive. Please follow the process at the link below to report the information we and then we can better answer your question:

https://www.atomicorp.com/wiki/index.ph ... _Positives

If you want to manually adapt the rules to your needs, and wish to use the free and unsupported rules, then you will need to read the documentation in the wiki as to what the rule classes do and how to adapt them to your needs.



They are in the real time rules, not yet in delayed rules. You'll have to wait for that with the delayed rules.

These are the rules I've had to disable based on my FP reports coming back as "Not our problem, disable the rule."

SecRuleRemoveById 340162
SecRuleRemoveById 300076
SecRuleRemoveById 300034

Thanks for the feedback, I do have some comments though on the three rules you recommend disabling.



Are you sure we told you to disable this rule? I also went through every time you reported an FP, and I only found one case for rule "340126" which resulted in an update to the rules (340162 is always updated, we never recommend you disable this rule). I also can't find any cases where someone said to disable this rule, could you please tell me where someone told you to do this?

If you are experiencing any FPs with this rule please report them, we WILL ALWAYS fix them.

Bottomline: Do NOT under any circumstances disable this rule. This rule protects your system from RFI attacks.



This rule detects hidden text. You reported a false positive while posting hidden text while using drupals comment feature. This part of drupal does not provide any context to tell if this is being uses as an open comment feature, or a closed one so unfortunately its not possible to tune this rule to allow this in some cases and not others.

I really wish there was a way to that with this FP you reported, but the app has only a few arguments to analyze:

comment
format
form_build_id
form_token
form_id
op

We were not able to come up with any way to analyze these variables to modify the rules for all users to conclude if this was an "open" or "closed"/authenticated comment. The concern is that if the rules are modified to allow this in general, and someone is using drupal but for lets say a blog, a spammer or malicious actor could use this same feature to post hidden content.

If you have any suggestions about how we might do this, please let us know.

The recommendation in this case was to disable this rule for that domain as you appear to be using this feature for internal development purposes.

With that said it is not recommended that drupal users disable this in general. Doing so will allow users to post hidden content to any part of a drupal managed site that allows users input (such as comment areas).

Please report an FPs with this rule, until this case, we've never run into an application where this rule couldnt be tuned, in this one instance it just doesnt seem possible. Again, if you have a suggestion we would be delighted to hear it. Honestly this is the first time I've seen an app provide so little information.



This rule detects the use of temporary directories that would not normally be used in a comment, such as links to the uploads directories on wordpress, template directories and so on. These directories are not normally linked to directly, and the intent of this rule is to catch potentially malicious or spam links in posts. It looks like in your case a user was commenting on internal file layout structures for a website, and our recommendation was to disable this rule for that domain if you wanted to allow links such as these.

It is not recommended that drupal users disable this in general. Doing so will allow users to post URLs that may point to malicious content.

I can't find anything like that. I don't remember what it was specifically, I think it might have been when I was trying to bring in an ical feed to the Atrium calendar. Disabling this rule fixed the problem at the time, I've re-enabled it now.


[/quote]

OK. Well, I'm not sure the best way to handle it, but I can't have my users/clients randomly shunned from the server because they're talking about their websites.

Yeah I cant any case other than the one I previously mentioned for rule 340162 where an update was released for that issue. With that said, if you have any problems with any rule, please report them. Except for the spam rules, we always release updates to adjust the rules. The spam rules are a bit tricky as they look at content, and its a little harder to say when that content is, or is not allowed. Your feedback on the rules is greatly appreciated, and to show you how much we appreciate it I've added a free year onto your ASL license.

If you run into any problems with the rules, or if you feel an answer the support staff has provided is not satisfactory please let us know immediately. Your satisfaction is very important to us, and we strive to make every part of ASL as easy to use and unobtrusive as possible.



I'll take a closer look then at how this part of drupal works. Its a shame it doesnt provide anymore information about the condition the request is in, it would be so much easier to create security rules if it did.

I've just pushed one update that may help you.

Wow mikeshinn, did not expect nor was fishing for that! I'm guessing my post came across as dissatisfied, didn't mean to imply that, I'm sorry! You guys have created a very valuable product/service and I'm happy with it.

Are you guys familiar with drupal in general? As far as application architecture, it's one of the more secure options out there. For this particular site that I was submitting FPs for, the users cannot register themselves, so it's only human-trusted people who can post anything. That's not generalized for *all* drupal installs, but for this one I know that when my users are posting "content" it's not evil. I'll see if I can come up with something helpful on a rule that would make more sense globally.

Really appreciate your help mikeshinn!