403 when query string contains a dot (.) character

htaccess apache 403-forbidden

6,458

Check the actual file you're running the query strings against to see if it is producing the 403 errors. If you create a PHP file that has the following contents and save it and then run it live on the server while using an actual dot in the query string, then you'll get the 403 error.

<?php
if (strpos($_SERVER['QUERY_STRING'],".") !== false){
    header("HTTP/1.0 403 Forbidden",true);
}
?>

6,458

intuited

// shenanigans

Updated on September 18, 2022

Comments

intuited over 1 year
EDIT: did more research, asked new question

I dug a bit deeper and realized that the contents of the page are indeed not relevant to this issue. As this question has gotten more and more confusing, I've asked a new question to avoid further muddying the waters.

EDIT: did some more detective work

I've created the following file to display query string parameters and set it up on my webserver:
```
<!DOCTYPE html> 
<html> 
<body> 

<script src="URI.js"></script>
<script>
var bodyEl = document.getElementsByTagName("body")[0];
var url = URI(document.documentURI);
var options = URI.parseQuery(url.query());
var optionsDiv = document.createElement("div");
var optionsText = "";
for (o in options) {
  optionsText += "" + o + ": " + options[o] + "\n";
}
optionsDiv.innerText = optionsText;
bodyEl.appendChild(optionsDiv);
</script>
</body>
</html>
```
It works as expected given the URL http://example.com/querytest/querytest.html?a=1&b=2.

When I send it query string parameters containing a %-escaped url, I get a 403 error from the webserver.

Example URL: http://example.com/querytest/querytest.html?a=1&b=2&source_url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D2Tjp0mRb4XA

However, if I substitute example.com for www.youtube.com in the %-escaped URL, I do not get a 303.

Based on this, I'm guessing that the library I'm using to parse the URL (URI.js) is doing something with the url that violates the same origin policy.

Original post

I'm using shared hosting, i.e. I have no ability to modify the apache installation, root configuration files, etc. I'm developing a web app that passes URLs as query string parameter values. The web server is giving a 403 FORBIDDEN error whenever the query string contains a period character, even if that character is %-escaped — i.e. either "."or"%2E"` in a query string value will trigger the 403.

It seems that the web server thinks that the file extension is everything after the final "." in the query string. How can I get it to act sensibly and realize that it's just part of the query string?

A .htaccess file in the web app's directory is used by Apache. I tried creating one containing the following line, but it didn't do the trick. It's been a while since I worked with Apache config, so I'm not surprised. The second line serves to verify that Apache is actually reading the local .htaccess file.
```
RewriteRule ^app.html$ app.html [L,NC,NS,QSA]
RewriteRule ^app$ app.html [L,NC,NS,QSA]
```
Note: originally posted on Stack Overflow but received little attention and no responses.
- Admin about 9 years
  
  The first rewrite example you gave is redundant. You should remove it. The second is perfectly valid but may not solve your problem. Can you give us examples of the failing URLs (JIC) so that we can be precise in helping you? Thanks!!
- Admin about 9 years
  
  Any URL for the page in question with a dot after the ‛?‛ seems to trigger the 403. Hmm actually perhaps I only tried cases where the dot is in the value (rather than the name) of a query string parameter.
- Admin about 9 years
  
  Sorry. I was out for a while. I getcha! But I guess what I was asking, albeit not very well, is what have you tried?? BTW- escape does not work, but encoding might. I am thinking that there has to be something in the configuration or .htaccess that is preventing this from working. I know that you do not have access to the configuration. Can you experiment with a hello world script that will take params outside of your app to see if you get the same behavior? In fact, just an HTML file will do. I use dots in my site params a lot so natively, this should not be an issue.
- Admin about 9 years
  
  What makes you think it is related to file extensions? Is there helpful error message shown?
- Admin about 9 years
  
  I did a bit of experimenting and found that the same behavior occurs for nonexistent files — i.e. a different error code is indicated by the server depending on whether or not there is a dot in the URL even if the URL does not point to a real file.
- Admin about 9 years
  
  As closetnoc suggests, we need to see some examples. %2F is not an encoded dot as you seem to imply; it is an encoded slash. And this can result in Apache rejecting the URL in some situations, but we need examples. Apache does not really have any concept of file extensions in the query string... It's simply a value if properly encoded.
- Admin about 9 years
  
  Hmm. I had assumed that since this worked okay when testing from a local file, the issue was with webserver configuration. After digging a little deeper, it seems like it might be an issue with same-origin policy and a library that I'm using. I'll post an update in a minute. Thanks, folks.
- Admin about 9 years
  
  How would a JavaScript library cause a 403 error? 403 errors have to be server side. You need to post example URLs that have this error along with some that don't. You should also find any relevant entries in your server's log file.
- Admin about 9 years
  
  That's what I thought, too. Actually, it turns out I was right in the first place — even with an empty HTML page, passing certain parameters causes an issue.
- Admin about 9 years
  
  I've managed to get things narrowed down more. I'll post a new question with these clarifications, since things have gotten pretty confused here.