View Full Version : bad_url redirect a Security Issue?
good1
28-Dec-2010, 09:35 PM
I use McAfee Secure on my website, it's recently found an exploit with my form. Apparently any value can be placed/subsituted in the bad_url hidden field in my form and the form then can be made to redirect to that the new URL. McAfee calls this vulnerablity "User specified URL redirection (Open Redirect)"
I tried creating a [special_fields] section in my INI and place my bad_url location in there however it did not work. Is that possible to do that? If so, how?
If the INI file placement for the bad_url value is not possible is there another solution to prevent just any URL from being used as the bad_url value?
russellr
04-Jan-2011, 09:52 PM
Hi,
Sorry for delay in responding - it's that time of year.
I think the "exploit" is theoretical only - that is, I don't think anyone could demonstrate an actual case where someone's security is actually harmed.
I believe the problem is related to the fact that FormMail will process forms using the GET method (the POST method is more usual).
We only support the GET method for the handful of broken servers that don't allow their webmasters to use the POST method.
So, the solution to this is to disable the GET method and only enable it under a configuration setting.
We'll implement this shortly, so keep an eye out for updates.
good1
04-Jan-2011, 09:55 PM
Excellent! Thank you!
good1
28-Mar-2011, 09:43 PM
Hello, I was just wondering if there has been any update to this?
Thanks!
russellr
30-Mar-2011, 10:56 PM
Hi,
We have made the changes and will release a new version of FormMail very shortly.
Thanks for following up.
russellr
20-May-2011, 06:32 AM
Hi,
Sorry it's taken a long time, but this is now changes, tested, and released.
Upgrade to version 8.27 and the GET method is disabled by default.
You can enable it again (for testing, or otherwise) with the $ALLOW_GET_METHOD configuration setting.
good1
19-Jul-2011, 08:34 PM
Apparently changing to POST did not fix the issue. The problem is that any URL can be substituted in the bad_url field, the script does not verify what that URL should be. Doing so allows phishing attacks to get users to visit malicious sites without realizing it.
This is what McAfee is telling me. Would like to know what you think. I had thought you could define the bad_url field in the INI but is that not the case?
Thanks for all your help with this!
russellr
19-Jul-2011, 11:31 PM
Hi,
Apparently changing to POST did not fix the issue. The problem is that any URL can be substituted in the bad_url field, the script does not verify what that URL should be. Doing so allows phishing attacks to get users to visit malicious sites without realizing it.
This is what McAfee is telling me. Would like to know what you think.
I'd like to see someone (such as McAfee) actually demonstrate this.
A phishing attack works by getting a user to go a webpage that looks like yours but isn't.
If they copy your form page, and adjust the URLs on that page, that's a phishing attack. They can adjust the URL in the <form> tag - that's the most obvious thing to do.
How is that different to copying any page on your site and adjusting the URLs on that copy?
We can certainly lock this down further using the $TARGET_URLS feature in FormMail.
If a real problem can be demonstrated, we'll certainly do that.
Can you ask McAfee to demonstrate how the attack they claim could be launched?
I had thought you could define the bad_url field in the INI but is that not the case?
Yes, you can set bad_url in the INI file.
It will override whatever is submitted from the HTML form.
good1
20-Jul-2011, 06:42 PM
Using the bad_url in the INI seemed to keep McAfee from flagging the issue. So I'm considering it resolved. Thanks for all your help!
Powered by vBulletin® Version 4.1.4 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.