here is my URL
http://abc.domain.com/controller/action/A74444C3A7FA858C7995CA9954CBCF1E26604634767C5575396D908E8415CF8CCC04C05F49FED0AA9D9743B69ABF232BDE9787A5222D081DA638896C0D2379A673E1747A2FFE1158F14AF098B2899D2ABEB4EA738D89369627E479796B6B2B9EA9B247CC59EF10E3A88B6A56A87F0818E2AD2A942FFA31F1C941BB7AF6FDC55FE6733353F28DFAC1827688604CBFBAB4856E6C75F810D13923F9D913F51F5B02980163E6CD63BC04610AD2C12E07360D7BC2C69F1B0CD03E
There are no invalid characters in the URL itself as everything is encrypted. Still I am getting
Bad Request - Invalid URL
HTTP Error 400. The request URL is invalid.
I know the URL is awfully long and I was able to resolve that issue in my Cassini by adding this
httpRuntime maxUrlLength="512"
in the web.config
However in IIS7 even after playing around with the requestfiltering maxurl and maxquerystring values I have not been able to resolve this.
This is an asp.net mvc 3 application.
This one is for posterity and for tracking my own problem. It's been said in another answer however, not as explicitly.
I've had the same problem on my end. The answer is of course to transfer the long URL segment to a Query string. Easier to handle.
The problem however is that HTTP.sys is not even letting the request through because a segment of the URL is exceeding 260 or so characters. However, we still had to support it.
You can change that setting in the registry. Once you reboot, the url will work.
Registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters]
"UrlSegmentMaxLength"=dword:00000400
This will effectively set the segment length to 1024.
Source
Your problem is you're not using a query string, but a path. A path has a maximum length of 255.
The final path segment is likely to be too long.
See: http://social.msdn.microsoft.com/Forums/nl/netfxnetcom/thread/723e6bfd-cab7-417b-b487-67f1dcfa524f
Related
I've noticed a large increase in the number of events logged daily that have &hash= in the URL. The requested URL is the same every time but the number that follows the &hash= is always different.
I have no idea what the purpose of the &hash= parameter is, so I'm unsure if these attempts are malicious or something else. Can anyone provide insight as to what is being attempted with the requested URL? I have copied in one from a recent log below.
https://www.movinglabor.com:443/moving-services/moving-labor/move-furniture/&du=https:/www.movinglabor.com/moving-services/moving-labor/move.../&hash=AFD3C9508211E3F234B4A265B3EF7E3F
I have been seeing the same thing in IIS on Windows Server 2012 R2. They were mostly HEAD requests. I did see a few other more obvious attack attempts from the same ip address so I'm assuming the du/hash thing is also intended to be malicious.
Here's an example of another attempt which also tries some url encoding to bypass filters:
part_id=D8DD67F9S8DF79S8D7F9D9D%5C&du=https://www.examplesite.com/page..asp%5C?part...%5C&hash=DA54E35B7D77F7137E|-|0|404_Not_Found
So you may want to look through your IIS logs to see if they are trying other things.
In the end I simply created a blocking rule for it using the Url Rewrite extension for IIS.
I m creating a code in which based on query string the URL is changing when no values are supplied in URL everything is working fine but as i supply values to URL it shows Error HTTP Error 403.0 - ModSecurity Action
Kindly suggest some solution
also the same is working fine in local problem occurs when i upload my webpage to server
I know this is an old thread, but posting the answer so that it can be helpful for others. ModSecurity is an open source, cross-platform web application firewall (WAF) module.
https://modsecurity.org/about.html
So whenever you see the 403 (ModSecurity Action), this means that the mod security firewall has blocked the request. The probable cause could be vulnerable data present in the posted data, or the it could be because of the URL posted as parameter or it could be JavaScript.
In above case, the ModSecurity might have deemed the input as SQL Injection attack and hence may have blocked it. If you look into the logs of the firewall it may give you the detailed explanation.
In my case, I was passing URL as query parameter in the request hence it was returning 403.
I'm currently working on an ASP.NET MVC website and it works fine.
But I have a problem that I don't understand at all... When I launch my website on Visual Studio with Chrome for example no problem, but when I stop it and try to launch an other test with Firefox for example, my url is growing and then I get this error :
HTTP 400. The size of the request headers is too long.
Can someone explain me why this is happening ? Is it something with my code or does it come from IIS express or anything else ?
Thanks in advance
You can probably increase the size of requests your webserver will allow. However, take a look at the amount and the size of cookies your browser are sending to the server. Clear your cookies and try again, and see if you can reduce the size and amount of cookies your app is using. The less, the better! Mobile browsers can get these errors, as they don't allow the same size as do desktop browsers(?).
The error can also mean the query string is getting too large.
.NET MVC SOLUTION FOR ME
In my case, it was my claims that was multiplying my session cookies to look as below in my browser cookies:
.AspNet.ApplicationCookie
.AspNet.ApplicationCookieC1
.AspNet.ApplicationCookieC2
.AspNet.ApplicationCookieC3
.AspNet.ApplicationCookieC4
.AspNet.ApplicationCookieC5
.AspNet.ApplicationCookieC6
.AspNet.ApplicationCookieC7
__RequestVerificationToken
I simply went to aspNetUserClaims table in my mssql management studio and cleared it. Then cleared the browser cookie for the project.
Refreshed the page. Kalas!!! Done!!
I believe it happened because I was switching from one database connectionstring to another which caused the claimsManager to recreate session and add to my cookie. On saturation, everyting exploded.
Check the MSDN:
Cause
This issue may occur when the user is a member of many Active
Directory user groups. When a user is a member of a large number of
active directory groups the Kerberos authentication token for the user
increases in size. The HTTP request that the user sends to the IIS
server contains the Kerberos token in the WWW-Authenticate header, and
the header size increases as the number of groups goes up. If the
HTTP header or packet size increases past the limits configured in
IIS, IIS may reject the request and send this error as the response.
Resolution
To work around this problem, choose one of the following options:
A) Decrease the number of Active Directory groups that the user is a
member of.
OR
B) Modify the MaxFieldLength and the MaxRequestBytes registry settings
on the IIS server so the user's request headers are not considered too
long. To determine the appropriate settings for the MaxFieldLength
and the MaxRequestBytes registry entries, use the following
calculations:
Calculate the size of the user's Kerberos token using the formula described in the following article:
New resolution for problems with Kerberos authentication when users belong to many groups
http://support.microsoft.com/kb/327825
Configure the MaxFieldLength and the MaxRequestBytes registry keys on the IIS server with a value of 4/3 * T, where T is the user's token
size, in bytes. HTTP encodes the Kerberos token using base64 encoding
and therefore replaces every 3 bytes in the token with 4 base64
encoded bytes. Changes that are made to the registry will not take
effect until you restart the HTTP service. Additionally, you may have
to restart any related IIS services.
try this
<system.web>
<httpRuntime maxRequestLength="2097151" executionTimeout="2097151" />
</system.web>
The maxRequestLength default size is 4096 KB (4 MB).
if browser request some resource again and again , at some time request header value length increase by number of times so we may try to extend request length to max length.
i hope this may usefull
In windows system generally this error occurs due to the default header size limits set in the http.sys service. This service acts as a protective layer before requests are forwarded to the application to prevent it from being overwhelmed by invalid requests.
You can override the default max header limit by modifying the windows registry.
Follow the steps :
Run regedit
From the address bar go to the address : Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters or drill down manually.
Right click on "Parameters" > New > DWORD
Rename the new entry to MaxFieldLength
Right click the newly created MaxFieldLength, modify it and set the value to desired max individual header size in bytes, make sure base is set to decimal.
Do the same for MaxRequestBytes. Make it sufficiently higher to match value set in MaxFieldLength.
Open command prompt as administrator
Enter the command "net stop http" (make sure visual studio or other interfering programs are closed)
Enter the command "net start http"
Resources:
Enabling logging
Supported parameters
In my case, I had cookies from a number of different apps served on my localhost with large cookies. FF differentiates by host-name so clearing my cookies from localhost fixed it.
Following Ifeanyi Chukwu's answer, for my case, I tried with private mode (Incognito) and it works fine. Then I go to browser settings and delete cookies of my site (localhost). That fixes the issue.
As you may already figured out issue, a simple temporary solution would be to switch your browser while debugging.
I have the need to redirect back to the current page minus any query arguments.
I just found Request.Url.AbsolutePath, which looks like it provides just the ticket to pass to Response.Redirect().
It seems to work on my dev machine okay. Does anyone know of any potential problems redirecting to the value of this property? It's hard to confirm it's "safe" in all cases.
It could be a problem if you "re-written" the URL internally. For example, the user request "/team.aspx" but internally you transfer execution or rewrite the url as "/page.aspx?id=137".
Personally, I prefer to use the Request.RawUrl (which is always local) and you can strip the query-string.
Getting rid of the host part of a request is not an issue because HTTP Redirect can be path on Absolute Paths ("/foo/bar") and the browser will preserve the protocol, port and hostname.
I would use Request.Url.OriginalString.
Absolute path gets rid of the host part of the URL.
Take a look at this: http://wdevs.blogspot.com/2009/03/url-properties-of-request-to-aspnet.html
I was getting 404 errors for some long URLs on a website I'm developing. After a bit of digging I discovered that this occurs when the length of certain aspects of the URL exceed configurable limits in IIS7. In this case the maxQueryString attribute of the requestLimits property needed to be increased in the web.config
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxQueryString="4096" maxAllowedContentLength="4096" maxUrl="8192" >
</requestLimits>
</requestFiltering>
</security>
This fixed the problem instantly on my development server but on the remote server I now get:
500 - Internal server error.
There is
a problem with the resource you are
looking for, and it cannot be
displayed.
And that's all the information it gives me.
Change your Flash to send the data as POST, so it won't be appended to the URL. Here's some sample code. Also, you may need to change the server side to look for the data as POST instead of GET.
Are you sure your hoster/production-server is running Windows Server 2008 (or 2008 R2)?
The settings you are describing above are only valid for IIS 7+.
You should not use such long URLs. Among other reasons, at least one of the common toolbars (Bing, Yahoo, Google) will break them, producing just such errors. Users will blame you.
I know this because one of my users was having just such a problem with a legacy app. When I removed the toolbars (she had all three installed!), the problem went away.
A GET request is only limited by a browser's limit on the length of the URL string.
In IE it is 2,083 characters, minus the number of characters in the actual path. Other browsers do not have a clearly defined limit on the length of the URL string. These articles might be helpful to you.
http://www.boutell.com/newfaq/misc/urllength.html
http://support.microsoft.com/kb/q208427
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length, so browsers are free to stipulate what they deem fit.
therefore you should use POST instead of GET if it's fits within your requirements