Forum Replies Created

Viewing 10 replies - 1 through 10 (of 10 total)
  • Well, the ruleset is already deprecated, so it’s a case of which hosting companies are still using them. We are still running a number of them as they still make sense, but we will be moving away from them soon. You now can see the rule which gave you the problem. I would try to find from other customers which rule stopped them (they will have to get this from their respective hosters) and look for similarities in the regex.

    Your dev would need to get their head round the SecRule syntax – but here are the two SecRule statements that make up the chain for rule 340464. As I say, though, we are dropping this ruleset soon, so it may be that it ceases to be an issue for you and more people find a different ruleset to use.

    SecRule ARGS|!ARGS:/banner/|!ARGS:/option/|!ARGS:/stream/|!ARGS:/analytics_code/|!ARGS:/endpoint/|!ARGS:_local|!ARGS:lookup|!ARGS:/hostname/|!ARGS:/cdn/|!ARGS:/^ad/|!ARGS:/image/|!ARGS:/target/|!ARGS:shrbase|!ARGS:facebook|!ARGS:/twitter/|!ARGS:/facebook/|!ARGS:/pinterest/|!ARGS:youtube|!ARGS:myspace|!ARGS:form|!ARGS:/logo/|!ARGS:/img/|!ARGS:unsubscribe|!ARGS:/^dest_to/|!ARGS:/rss/|!ARGS:/lm_slide/|!ARGS:/feed/|!ARGS:/footer/|!ARGS:/^jsfiles/|!ARGS:/include/|!ARGS:/pagination/|!ARGS:/link/|!ARGS:/image/|!ARGS:/path/|!ARGS:/page/|!ARGS:field_b|!ARGS:/refer/|!ARGS:/^gbu0_/|!ARGS:/site/|!ARGS:/button/|!ARGS:guestbookLink|!ARGS:xmlpath|!ARGS:/^update/|!ARGS:/^woo_ad/|!ARGS:act_filepath|!ARGS:/domain/|!ARGS:opphomepage|!ARGS:echi_google_analytics|!ARGS:/^echi_block_/|!ARGS:/^echi_ad/|!ARGS:/icon/|!ARGS:descripcion|!ARGS:xcont_priv|!ARGS:/comments/|!ARGS:email|!ARGS:/video/|!ARGS:hometext|!ARGS:/text/|!ARGS:web|!ARGS:/^config/|!ARGS:/^g2_manualpath/|!ARGS:/^sDescription/|!ARGS:hidepost_content_text|!ARGS:sText|!ARGS:sfhome|!ARGS:homepage|!ARGS:field_3_name|!ARGS:cforms_cmsg|!ARGS:bcontent|!ARGS:form_location|!ARGS:footer|!ARGS:field_4_name|!ARGS:cforms_redirect_page|!ARGS:cforms_action_page|!ARGS:ecards_more_pic_target|!ARGS:message|!ARGS:/^xfoot/|!ARGS:/^rss/|!ARGS:/rss$/|!ARGS:/^FCKeditor/|!ARGS:/url/|!ARGS:/redirect/|!ARGS:/page/|!ARGS:content|!ARGS:/linkedin/|!ARGS:outbound|!ARGS:out|!ARGS:/twitter/|!ARGS:/^field/|!ARGS:/button/|!ARGS:/facebook/|!ARGS:/pinterest/|!ARGS:/youtube/|!ARGS:/affredir/|!ARGS:helpbox|!ARGS:return|!ARGS:comment|!ARGS:basehref|!ARGS:redirect|!ARGS:oaparams|!ARGS:loc|!ARGS:resource|!ARGS:thelink|!ARGS:params[altTag]|!ARGS:filecontent|!ARGS:inc|!ARGS:link|!ARGS:fck_body|!ARGS:fck_brief|!ARGS:introtext|!ARGS:resource_box|!ARGS:areaContent2|!ARGS:ref|!ARGS:userpicpersonal|!ARGS:body|!ARGS:linkdescr|!ARGS:Post|!ARGS:last_msg|!ARGS:params[link]|!ARGS:texty|!ARGS:params[request_url]|!ARGS:pay_list_type|!ARGS:FULL_URL|!ARGS:HOMEPAGE_URL|!ARGS:ATTACHMENTS_URL|!ARGS:templatePath|!ARGS:fulltext|!ARGS:stories_cat|!ARGS:sUrl|!ARGS:config_helpurl|!ARGS:website_link|!ARGS:view|!ARGS:redirect_to|!ARGS:return_link_url|!ARGS:oldmsg|!ARGS:lk_url|!ARGS:config[latestNewsRRS]|!ARGS:sponsor|!ARGS:config[ftp_server]|!ARGS:listViewerCode|!ARGS:/element/|!ARGS:/google/|!ARGS:courier_tracking|!ARGS:/field_id/|!ARGS:/social_profile/ "^(?:ogg|gopher|data|php|zlib|(?:ht|f)tps?):/"  "chain,t:none,t:urlDecodeUni,t:base64Decode,t:hexDecode,t:htmlEntityDecode,t:lowercase,multimatch,id:340464,rev:53,severity:2,msg:'Atomicorp.com UNSUPPORTED DELAYED Rules: Remote File Injection attempt in ARGS (admin.php)',deny,status:403"
    SecRule MATCHED_VARS "!@rx ://%{SERVER_NAME}/"

    The ASL delayed rulesets in question are actually deprecated now by ASL, but the actual regex’s used are still valid tests against remote code injection attacks. I’m not sure what the rules are on the real-time ASL rulesets but will check.

    I have just helped a customer out with this same problem… Modsecurity is blocking the requests from the nextgen admin page due to rule interceptions.

    Match of “rx ://%{SERVER_NAME}/” against “ARGS:highslide[css_stylesheets]”

    An argument highslide[css_stylesheets] contains the server name.

    This rule exists in Atomic Security’s delayed ruleset rules #340464 and #340465 – you can ack your host to exclude these rules, or better still ask NextGen to improve their code to avoid the issue.

    Perhaps your other theme has overridden the bundled version of jquery that ships with WP? As already said, to get it to work, just go to

    http://www.no-margin-for-errors.com/projects/prettyphoto-jquery-lightbox-clone/

    download the latest version, and replace the prettyPhoto js file, css and images directories πŸ™‚

    Forum: Plugins
    In reply to: Problem with Permalinks

    Hi Jason, out of interest, which other solutions have you looked at? I’m looking at shopperpress, as it also supports sagepay out of the box.

    Forum: Plugins
    In reply to: Problem with Permalinks

    Join the club. I just upgraded to 3.8.1 from 3.7.8 – Straight away it broke every page with a 404 error – then updating the permalinks twice (??!!) to frig it, finally got it sort of working, but then it failed again after adding another page. As you say, it works fine without friendly permalinks… I think it’s just plain flakey – and pretty disappointed as I was planning to use it on a couple of projects I have ongoing.

    Actually, the problem with Jquery 1.4.4 affects all versions of prettyPhoto prior to 3.0.1 so the best solution is to download prettyPhoto 3.0.1 from the link above, and overwrite the whole prettyPhoto installation – images, css the lot, as the new version has a neat inline gallery selector as well, which will break with the old CSS.

    Yup, I found this too… doesn’t seem to upset anything else on my site to just use the 1.4.2. that ships with WPPP… Will be interesting to see what borked it!

Viewing 10 replies - 1 through 10 (of 10 total)