%2F in Url Breaks and Does Not Reference to the .PHP File Required

%2F in URL breaks and does not reference to the .php file required

Urls with %2f / or %5c \ return a 404 from Apache for security purposes.

You may modify Apache config to enable AllowEncodedSlashes On or NoDecode. Keep in mind that this may introduce unintended security issues, which this "feature" is designed to mitigate.

Apache docs: http://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes

Solved:

• Receive an HTTP 400 error if %2F is part of the GET URL in JBOSS

This one got me too -- thanks for the question

htaccess rewrite rule doesn't like a url encoded / (%2F)

I found the solution for Apache

You have to enable encoded slashes

AllowEncodedSlashes On

Receive an HTTP 400 error if %2F is part of the GET URL in JBOSS

Finally figured out the cause of this (both for JBoss and Apache). Both applications intentionally reject URIs with an encoded slash (%2F for / and %5C for \) to prevent possible security vulnerabilities.

Links:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0450

http://securitytracker.com/id/1018110 (Look at section 4. Solution)

And here are the instructions they provide for enabling this behavior in JBoss:

Note: In response to CVE-2007-0450, JBoss AS considers encoded slashes and backslashes in URLs invalid and its usage will result in HTTP 400 error. It is possible to allow encoded slashes and backslashes by following the steps outlined below, however doing so will expose you to CVE-2007-0450 related attacks:

a) If you use the /var/lib/jbossas/bin/run.sh setup, please edit /etc/jbossas/run.conf and append

- -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

- -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true to the string assigned to JAVA_OPTS

b) If you use the init script setup to run multiple JBoss AS services and you wish to allow encoding by default on all services, please edit /etc/jbossas/jbossas.conf and add the line JAVA_OPTS="${JAVA_OPTS}

- -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

- -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true"

c) If you use the init script setup to run multiple JBoss AS services and want to allow encoding of slashes and backslashes for a particular service, please edit /etc/sysconfig/${NAME} (where NAME is the name of your service) and add the line JAVA_OPTS="${JAVA_OPTS}
- -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
- -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true"

For Apache, it's as simple as setting "AllowEncodedSlashes NoDecode" somewhere in your apache conf or vhost conf (doesn't work in an .htaccess, however).

Apache link: http://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes

urlencoded Forward slash is breaking URL

Apache denies all URLs with %2F in the path part, for security reasons: scripts can't normally (ie. without rewriting) tell the difference between %2F and / due to the PATH_INFO environment variable being automatically URL-decoded (which is stupid, but a long-standing part of the CGI specification so there's nothing can be done about it).

You can turn this feature off using the AllowEncodedSlashes directive, but note that other web servers will still disallow it (with no option to turn that off), and that other characters may also be taboo (eg. %5C), and that %00 in particular will always be blocked by both Apache and IIS. So if your application relied on being able to have %2F or other characters in a path part you'd be limiting your compatibility/deployment options.

I am using urlencode() while preparing the search URL

You should use rawurlencode(), not urlencode() for escaping path parts. urlencode() is misnamed, it is actually for application/x-www-form-urlencoded data such as in the query string or the body of a POST request, and not for other parts of the URL.

The difference is that + doesn't mean space in path parts. rawurlencode() will correctly produce %20 instead, which will work both in form-encoded data and other parts of the URL.

Apache .htaccess redirection issue

Finally solved the problem with some further digging through StackOverflow.

First idea was just to read the $_SERVER['REDIRECT_REDIRECT_METHOD'] but I would NOT recommend doing this, as it turns out that Apache was also forcing a 404 response code during this redirect, meaning any URLs with an encoding %2F were returning as Not Found (Even with my page content showing up).

Answer came from this other question.

Solution:

# Set this rule in .htaccess/httpd.conf
AllowEncodedSlashes NoDecode

Show customized error page for forbidden request

You can add to your httpd.conf

AllowEncodedSlashes On 

And restart apache.

After that apache should treat your url as valid. ( so 404 page should be shown )

---

Related Topics