XSS attack with querystring tampering generates exception

1.4k Views Asked by At

I have one site hosted in asp.net 4.5. I have received several exception from particular URL.

Exception: "Could not load file or assembly 'http' or one of its dependencies. The system cannot find the file specified."

URL "default.aspx?_TSM_CombinedScripts_=http://some-inexistent-website.acu/some_inexistent_file_with_long_name?.123,%20Culture=neutral,%20PublicKeyToken=28f01b0e84b6d53e:en-US:e669ce41-1aa1-4541-aae9-fa5dc37e70db:475a4ef5:effe2a26:7e63a579&_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField"

I think someone tried XSS with some malicious link on my website.

I have checked view source of the page and found that AjaxToolKit creates similar src link as below which loads perfectly without error in browser.

default.aspx?_TSM_HiddenField_=MainContent_objucSignUp_atsm_HiddenField&_TSM_CombinedScripts_=%3B%3BAjaxControlToolkit%2C%20Version%3D4.5.7.123%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3D28f01b0e84b6d53e%3Aen-US%3Ae669ce41-1aa1-4541-aae9-fa5dc37e70db%3A475a4ef5%3Aeffe2a26%3A7e63a579

The difference is "some-inexistent-website.acu/some_inexistent_file_with_long_name?.123," and "AjaxControlToolkit" in both the URL.

In former URL which is generating exception if I replace that "some-inexistent-website.acu/some_inexistent_file_with_long_name?.123," with "AjaxControlToolkit" then it works fine.

How can I handle this type of malicious link so that exceptions are not generated?

I am thinking of return that has "_TSM_CombinedScripts" part in the URL but does not have "AjaxControlToolkit" in it.

Is this the best way to solve?

Can I prevent such URL from generating exceptions by some other way?

2

There are 2 best solutions below

0
On BEST ANSWER

I have replaced ToolScriptManager with ScriptManager as latest scriptmanager is enhanced to incorporate functionalities of ToolScriptManager.

That worked for me to override this problem.

0
On

It looks like the attacker was searching got a remote-file-inclusion attack of some kind, but this doesn't look like a very sophisticated attack, probably some automated script that tries to inject everything he can anywhere he can.

But anyway I'm wondering - why are you trying so bad to prevent an error with a bad input? Preventing this specific error won't do any good, there are probably thousands of other ways to cause errors in your app, and this is perfectly fine as long as you don't reveal detailed error messages and redirect the user to a general error page that doesn't reveal the cause of the error (you can display a auto incremented code the corresponds to a log record for support purposes).

In the most extreme case, if someone is generating exceptions to bombard your logs, you can try anti DDoS and throttling solutions to prevent flooding.