About a week ago, our IIS server started getting hits on a single page with a very long query string. Multiple key-value pairs where both the key and the value were just random characters. The page is always the same. The page is shtml so it does not expect or use any query string variables.
Each hit had a completely unique query string. Here are some examples:
Zgmgi=zSYF1I82nna&WopGF=NoH4zLwdxLB&V89l2=HnpJsD0FJs&MKmeop=TQqf1ih6d4&Im3ae=UOyGEB6ES5&yWpB5j=QUzTmMBz0St&iKVcYwm=n99RUVUKE2&NBnVP7=H5M2vMsOMo&Kxbzrx7=9IcEmiKIoBq&cxlJe=vnwmKaKWXT5&OnFL0=idbQiRNt76&
M5KtGSd=QOL7MuGFD15&Rw7zcXi=Jq3QmkjLsx&QtEmDNv=v7ulHE77t4T&Hpbw45=WSMfPCbZig&S14KS4=Hw3jo3tEzeZ&wgUpRz=l2KfUkO6x2&qcDox=kEFEhraHZgS&JWf1Ia=PhmyHOioHB&en6gDG7=hZHl1tNvLk&ydRFTwQ=IgmQvKse0yD&r6SHx=7G6wP1QksU&F2gwZ=6fTYKzDek7&
I have pasted them into a couple of decoders (uri, base64) and they don't come up with anything. Is there something obvious that I could be missing? I do not want to overlook some sort of attack attempt?
From description, this could be a kind of DDOS attack. Attacker will send random Querystrings request to your page. It is a kind of flood attack, which send massive requests to make your sever overload. The querystring is just random and meaningless.
You can add this rule to your request filtering module on IIS. This rule deny all request with "=" in the querystring (actually deny all query) to .shtml file.
Related
I'm having a URL like this:
http://www.foobar.com/
If a user enters it, I want the URL to be expanded by a random string like
http://www.foobar.com/f896c0fb0924db5dfeae58d430c2d6ca
(In the example a MD5 is added, but it anything else would be fine too.)
Is it possible to do this via .htaccess and some clever Rewrite-rules?
It is possible to do it with mod_rewrite, but the programmatic mode (prg) needs to be defined in the server config (you can only use them then from .htaccess). You could come close with a long chain of predefined strings (meh) or use other pseudo-random sources. One option is to combine various TIME server variables like TIME_SEC. With repeats and without separators, it would not be easy to notice the pattern.
I am trying to figure out how to use the ampersand symbol in an url.
Having seen it here: http://www.indeed.co.uk/B&Q-jobs I wish to do something similar.
Not exactly sure what the server is going to call when the url is accessed.
Is there a way to grab a request like this with .htaccess and rewrite to a specific file?
Thanks for you help!
Ampersands are commonly used in a query string. Query strings are one or more variables at the end of the URL that the page uses to render content, track information, etc. Query strings typically look something like this:
http://www.website.com/index.php?variable=1&variable=2
Notice how the first special character in the URL after the file extension is a ?. This designates the start of the query string.
In your example, there is no ?, so no query string is started. According to RFC 1738, ampersands are not valid URL characters except for their designated purposes (to link variables in a query string together), so the link you provided is technically invalid.
The way around that invalidity, and what is likely happening, is a rewrite. A rewrite informs the server to show a specific file based on a pattern or match. For example, an .htaccess rewrite rule that may work with your example could be:
RewriteEngine on
RewriteRule ^/?B&Q-(.*)$ /scripts/b-q.php?variable=$1 [NC,L]
This rule would find any URL's starting with http://www.indeed.co.uk/B&Q- and show the content of http://www.indeed.co.uk/scripts/b-q.php?variable=jobs instead.
For more information about Apache rewrite rules, check out their official documentation.
Lastly, I would recommend against using ampersands in URLs, even when doing rewrites, unless they are part of the query string. The purpose of an ampersand in a URL is to string variables together in a query string. Using it out of that purpose is not correct and may cause confusion in the future.
A URI like /B&Q-jobs gets sent to the server encoded like this: /B%26Q-jobs. However, when it gets sent through the rewrite engine, the URI has already been decoded so you want to actually match against the & character:
Rewrite ^/?B&Q-jobs$ /a/specific/file.html [L]
This makes it so when someone requests /B&Q-jobs, they actually get served the content at /a/specific/file.html.
This is possibly a duplicate question, but I am unable to find the other one if it is.
I was looking for advice on how secure url rewriting is? Does it stop SQL injection, or XSS? If not, how would one circumvate it?
The reason I ask is because I am unsure of the process that rewriting takes. Am I right in believing that this URL could effectively be dangerous:
http://www.website.com/article/1' UNION ALL...
URL rewriting doesn't have anything to do with preventing SQL injections! URL rewriting is mostly used to turn "ugly" URLS (like http://domain.com/index.php?name=1&value=2) into pretty URLs like http://domain.com/1/2).
It doesn't prevent SQL injection at all. SQL injection must be prevented by making sure that user inputs do not contain characters that modify an SQL statement so that it does things that were not intended. Example:
You have an SQL Statement like:
SELECT * FROM $tableName;
And $tableName is a parameter that is entered by the user through a web form. Now the user could enter Users; DROP TABLE Users; --. This would be bad:
SELECT * FROM Users; DROP TABLE Users; --;
This, however, can not be solved by URL rewriting.
no, URL rewrite couldn't prevent XSS or SQL Injection.
If you want to avoid SQL Injection, use DBI Library (with prepare/execute statement) in your code.
If you want to avoid XSS Attack, please filter your user input in your code, too.
URL rewriting and security are two different things. The URL rewrite simply changes the presentation of variables in the url but does not secure at all. We must secure the variables in your code after you recover from the url.
But for SQL Injection based only on the $_GET variable, if we use this:
RewriteRule ^([a-z])-([0-9]).html$ /index.php?page=$1&id=$2 [L]
Is the $_GET["id"] variable injectable? We are forcing the value with only integer.
URL rewriting has feature called 'Request blocking'. You can use this feature to scan and prevent 3rd party tools sending spoof requests.
I want to redirect every post 301 redirect, but I have over 3000 posts.
If I list
Redirect permanent /blog/2010/07/post.html http://new.blog.com/2010/07/23/post/
Redirect permanent /blog/2010/07/post1.html http://new.blog.com/2010/07/24/post1/
Redirect permanent /blog/2010/07/post2.html http://new.blog.com/2010/07/25/post2/
Redirect permanent /blog/2010/07/post3.html http://new.blog.com/2010/07/26/post3/
Redirect per......
for over 3000 url redirect command in .htaccess would this eat my server resource or cause some problem? Im not sure how .htaccess work but if the server is looking at these lists each time user requests for page, I would guess it will be a resource hog.
I can't use RedirectMatch because I added date variable in my new url. Do you have any other suggestions redirecting these posts? Or am I just fine?
Thanks!
I am not an Apache expert, so I cannot speak to whether or not having 3,000 redirects in .htaccess is a problem (though my gut tells me it probably is a bad idea). However, as a simpler solution to your problem, why not use mod_rewrite to do your redirects?
RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/$3/ [R=permanent]
This uses a regex to match old URLs and rewrite them to new ones. The [R=permanent] instructs mod_rewrite to issue a 301 with the new URL instead of silently rewriting the request internally.
In your example, it looks like you've added the day of the post to the URL, which does not exist in the old URL. Since you obviously cannot use a regexp to divine the day an arbitrary post was made, this method may not work for you. If you can drop the day from the URL, then you're good to go.
Edit: The first time I read your question, I missed the last paragraph. ("I can't use RedirectMatch because I added date variable in my new url.") In this case, you can use mod_rewrite's RewriteMap to lookup the day component of a post.
You have two options:
Use a hashmap to perform fast lookups in a static file. This means all your old URLs will work, but any new posts cannot be accessed using the old URL scheme.
Use a script to grab the day.
In option one, create a file called posts.txt and put:
/yyyy/mm/pppp dd
...for each post where yyyy is the year of the post, mm is the month, and pppp is the post name (without the .html).
When you're done, run:
$ httxt2dbm -i posts.txt -o posts.map
Then we add to to the server/virtual server config: (Note the path is a filesystem path, not a URL.)
RewriteMap postday dbm:/path/to/file/posts.map
RewriteRule ^/blog/(.+)/(.+)/(.+).html$ http://new.blog.com/$1/$2/${postday:$1/$2/$3}/$3/ [R=permanent]
In option two, use pgm:/path/to/script/lookup.whatever as your RewriteMap. See the mod_rewrite documentation for more info about using a script.
Doing the lookup in mod_rewrite is better than just redirecting to a script which looks up the date and then redirects to the final destination because you should never redirect more than once. Issuing a 301 or 302 incurs a round trip cost, which increases the latency of your page load time.
If you have some way in code to determine the day of a post, you can generate the rewrite on the fly. You can setup a mod_rewrite pattern, something like .html and set up a front controller pattern to calculate the new url from the old and issue the 301 header.
With php as an example:
$_SERVER['REQUEST_URI']
will contain the requested url and
header("Location: http://new.blog.com/$y/$m/$d/$title/",TRUE,301);
will send a redirect.
That's... a lot of redirects. But the first thing I would tell you, and probably the only thing I can tell you without qualification, is that you should run some tests and see what the access times for your blog are like, and also look at the server's CPU and memory usage while you're doing it. If they're fairly low even with that giant list of redirects, you're okay as long as your blog doesn't experience a sudden increase in traffic. (I strongly suspect the 3000 rewrites will be slowing Apache down a lot, though)
That being said, I would second josh's suggestion of replacing the redirects with something dynamic. Like animuson said, if you're willing to drop the day from the URL, it'll be easy to set up a RewriteRule directive to handle the redirection. Otherwise, you could do it with a PHP script, or generally some code in whatever scripting language you (can) use. If you're using one of the popular blog engines, it probably contains code to do this already. Basically you could do something like
RewriteRule .* /blog/index.php
and just let the PHP script sort out which post was requested. It has access to the database so it'll be able to do that, and then you can either display the post directly from the PHP script, or to recover your original redirection behavior, you can send a Location header with the correct URL.
An alternative would be to use RewriteMap, which lets you write a RewriteRule where the target is determined by a program or file of your choice instead of being directly specified in the configuration file. As one option, you can specify a text file that contains the old and new URLs, and Apache will handle searching the file for the appropriate line for any given request. Read the documentation (linked above) for the full details. I will mention that this isn't used very often, and I'm not sure how much faster it would be compared to just having 3000 redirects.
Last tip: Apache can be significantly faster if you're able to move the configuration directives (like Redirect) into the server or virtual host configuration file, and disable reading of .htaccess entirely. I would guess that moving 3000 directives from .htaccess into the virtual host configuration could make your server considerably faster. But even moving the directives into the vhost config file probably wouldn't produce as much of a speedup as using a single RewriteRule.
It's never a good idea to make a massive list of Redirects. A better programming technique is to simply redirect the pages without that date variable then have a small PHP snippet that detects if it's missing and redirects to the URL with it included. The long list looks tacky and slows down Apache because it's checking that URL (any every other URL that might not even be affected by this) against each line. If it were only 5 or so, I'd say fine, but 3,000 is a definite NO.
Although I'm not a big fan of this method, a better choice would be to redirect all those URLs normally using a single match statement, redirecting them to the page without the date part, or with a dash or something, then include a small PHP snippet to check if the date is valid and if not, rewrite the path again to the correctly formed URL.
Honestly, if you didn't have that part there before, you don't need it now, and it will probably just confuse the search engines changing the URL for 3,000 posts. You don't really need a date in the URL, a good title is much more meaningful not only to users, but also to search engines, than a bunch of numbers.
I figured out how to redirect someone, if they happen across one particular filename:
Redirect /index.php http://www.website.com/#myaccount
As you can see, I'm pretty much redirecting that visitor to the same page, which doesn't work. It's an endless look, regardless of the slight/minuscule change.
I want to force someone to see a part of the page, by adding the hash. (it's a little weird, I know)
I'm guessing this may be a time to use regex in the htaccess file.
But I thought I'd ask if there's a simpler way to do this from the htaccess file.
The fragment of an URI (the part after the first #) is not sent to the server. That means you cannot use server side techniques to test if the fragment has a certain value of does exist at all; only client side techniques like JavaScript can do that.