we were all recently alerted by scottgu with this security vulnerability. http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
I'm wondering, since I've been redirecting errors via Global.asax on the Application_Error event, I was wondering if that can suffice the fix for this issue or do I still need to place a setting on the web.config?
The problem is that (according MS) you need to respond ALWAYS in the same way, no matter the specific error you have.
You'd need to redirect the user to the same page on errors 404 and 500. That's why the easiest way would be using the web.config setting.
They say that this would be temporary and you could revert it once they release a patch for this.
This is the Scott answer to a similar question:
I would recommend temporarily updating the module to always redirect to the search page. One of the ways this attack works is that looks for differentiation between 404s and 500 errors. Always returning the same HTTP code and sending them to the same place is one way to help block it.
Note that when the patch comes out to fix this, you won't need to do this (and can revert back to the old behavior). But for right now I'd recommend not differentiating between 404s and 500s to clients.
Related
I stumbled upon some strange behaviour today on a website at work. Our SEO consultant wanted some strange looking links taken away from Googles index, a seemingly straight-forward task. But it turned out to be very difficult.
The website was a .net MVC 5.2.3 application. We looked at routing, our own libraries etc. Nothing strange. After a while we gave up and tried simply redirect request to these urls by setting up a rule in web.config. Turns out these URL:s are unmatchable! Somehow under the right conditions the critical part of the URL seem to avoid matching rules as well as routing later on in the MVC application.
We narrowed down the mystical URL:s to the format (T(anything)) where T can by any capital letter and anything can be eh, anything. This is placed in the beginning of the URL as if it were a directory. In regex: \([A-Z]\([a-zA-Z0-9]*\)\)
I've tested and found the same behaviour on:
.net MVC5 sites
.net MVC3 sites
.net Web Forms sites
http://asp.net
http://stackoverflow.com
Some examples from stackoverflow.com:
Bypasses routing: https://stackoverflow.com/(K(jonas))/questions
Routes normal (404): https://stackoverflow.com/jonas/questions
Bypasses routing: https://stackoverflow.com/(G(hello))/users/1049710/jonas-%C3%84ppelgran
Routes normal (404): https://stackoverflow.com/gandhello/users/1049710/jonas-Äppelgran
It doesn't seem to affect the whole web, so it shouldn't be a browser or HTTP issue. Some examples:
Routes normal (404): http://php.net/(T(testing))/downloads
Routes normal (404): https://www.iana.org/(T(testing))/domains/reserved
Can anybody explain what is going on?
And what I can do to prohibit these URL:s to bypass routing?
Apparently this is a feature called a "cookieless session" in ASP.NET. See "Cookieless SessionIDs" section here in the MSDN docs.
The basic idea is that instead of storing the session id (if session state is enabled) in a cookie, it's now embedded in the URL.
We (Stack Overflow) disable session state entirely (by setting sessionState mode to off). As far as I know, the end result is that any time one of the URLs that match the session id format is used, that information is simply discarded.
None of the links leading to us in Google include it either, which makes me think that your site may be configured to actually generate session IDs in URLs? Short of disabling the feature, there's probably not much you can do here. Although, see "Regenerating Expired Session Identifiers" on the MSDN page I linked above to see how to at least prevent accidental session sharing if that's not already done.
What would cause IIS to return a 404, only sometimes? If I hit a 404 on a page, I can simply hit refresh and it will come up. It's reproducible. I've used fiddler to see what's going on and I don't see anything off. I've setup IIS tracing but again, I don't see what exactly the issue would be, the file exists and the 404 only occurs sometimes. By sometimes I mean if I navigated to a page and got a 404 I could refresh and it would come up but other times I could navigate to that page and it would not 404. It isn't limited to any one page or condition.
What other things can I try to determine what the issue is?
If you've run Fiddler and you see the request arrive at the server and you see a 404, then this doesn't sound like a web farm problem.
You might want to try SysInternals ProcMon to see what's going on underneath.
The usual reason for this is that you have a web farm with several machines, on one machine the pages are missing.
Therefore, each time you randomly use the machine with the missing pages you get a 404.
I've had this similar issue and I traced it back to changing this:
<modules runAllManagedModulesForAllRequests="true" />
to:
<modules runAllManagedModulesForAllRequests="false" />
Obviously, analysis will need to be done to make sure that this doesn't affect your application in any other way.
I have only has this when an MVC application because for certain situations my routes were not correct. Clicking would produce the 404 but F5(refresh) would show the webpage correctly. You don't mention mvc but thought it worth throwing this in.
The issue: a content editor saves a new content item and gets a 404 on the proper-looking url for the new object. If they then refresh, the item is there, perfectly normal.
This happens for multiple Archetypes-based content types, and we've seen it on at least two different sites. We've seen it on Plone 3.x and 4.0.3. Here's what these sites have in common:
HAProxy load balancing (with and without session affinity)
Multiple ZEO clients
Using either ZODB 3.9.7 or 3.8.4
The issue happens only some of the time, maybe for 1 out of 4 content items
Has anyone seen anything like this?
I do not have an answer for you; this should not really happen. I certainly have not seen this.
You'll need to gather more information to troubleshoot this, and that perhaps requires interactive access to experts, and SO is not the place for such troubleshooting.
All I can do is advice that you gather as much information as possible, including a full trail of the user interaction from the various logs, including HAProxy and the ZEO server.
It may require additional instrumentation at the server level (when the NotFound error occurs, dump additional information about what is present, etc).
Some recomendations/questions:
Verfy that the content object was, indeed, created.
Check that the content views are correct (the ones that are declared in profiles/default/types/yourtype.xml).
Does it happen when adding content directly to plone instance (Without caching and load balancing?
Does it happen when adding content to direct plone instance with load balancing, but without caching? ---> And so on ...?
Maybe not an elegant one, but you might try inserting print statements or pdb breakpoints in the code so you can track whenever a content object was, indeed, created. Do this only as a desperate method of "instrumentation".
Yes. we have recently started seeing the same issue. We have almost the same setup. Haproxy (no session affinity).
I'm wondering since the pattern seems to be haproxy... perhaps its an issue with a request being redistributed after a timeout?
Updated:
We had this issue. It happens when you have a redirect back to the changed object after a save. This is because the 2nd request hits another zeo client which doesn't realise it's out of date.
The only solution we found was a to add temporary session affinity in haproxy (20s) during any POST. Not ideal but does work. I was just searching for a better solution which is why I found this old post.
I posted a query for 301-redirect using ASP.NET 3.5 here:
Redirecting default.aspx to root virtual directory
Based on the replies I got there, I realized there might be a bug in ASP.NET's Request.RawUrl method which is unable to return the actual raw url (without /default.aspx) when being used in a sub-directory, i.e. the /default.aspx page is inside a subdirectory.
Can someone please shed some light on this possible bug?
Thanks,
Asif
i found a good explanation here
http://codeasp.net/blogs/vivek_iit/microsoft-net/873/301-redirect-from-default-aspx-to-site-root
Thanks
If you suspect this is a bug, then the place to go is Microsoft Connect, where you can report and discuss the bug directly with Microsoft.
Edit: I was able to reproduce the look per your comments.
I was unable to reproduce the infinite loop, however. I injected code into the Global.asax Application_BeginRequest handler of a web application and got the expected behavior of a single redirect.
There are other, and IMO much better, options for handling global redirect rules. On IIS7, I use the URL Rewrite module to configure rewrite rules in IIS. You can read more about it and download it here: http://www.iis.net/download/urlrewrite. The appeal of a solution such as this is that you can customize and update your rewrite rules without recompiling the application.
Edit: I was able to retrieve the raw URL without the default.aspx (after the redirect) by using instead:
Request.ServerVariables["CACHE_URL"]
It's worth a shot.
Have you looked at the IIS settings for your virtual directory? If there is a default document set to default.aspx then this will explain the infinite loop that you are experiencing. You are telling the website to redirect to the virtual directory without the "default.aspx" and IIS is detecting this on the next request and putting it back in ad infinitum.
Right click your virtual directory, select Properties and then the Documents tab. If default.aspx is in the list then that is what you will get. The Url of the request will be passed to the ASP.NET worker process as /folder/default.aspx rather than /folder/
This is not a bug. If IIS didn't do this, you would get a page not found error.
Sounds to me like you need to investigate URL rewriting: http://msdn.microsoft.com/en-us/library/ms972974.aspx
Up till now we've been rewriting URL's using a custon 404 page: the url would not map to any file in the site, and we configured the IIS to send 404 error to a aspx page which redirected those url's to the correct URL.
Now we want to stop using redirects, so after reading Scott Guthrie's article on Url Rewriting, I want to use the Application_BeginRequest in Global.asax. The thing is that a lot of our url's are not rewrites, and can get to the right place without any intervention. I'm worried that now every single request is going to have to go through the Application_BeginRequest method (even the un-rewritten url's), and I'm afraid it will slow down their loading time.
What do you think? Is loading time an issue when using Application_BeginRequest?
Every request goes through Application_BeginRequest anyway.
You'll need to add some logic so only those pages that need to be rewritten are changed.
That small bit of logic won't be very expensive.
I've used it, and didn't notice performance suffering at all.
There are very robust solutions out there if you are going to use it more frequently and that imitate Apache module mod_rewrite, i like this one because i have used it and it gave me no problem:
http://www.codeplex.com/IIRF
or:
http://urlrewriter.net/
http://www.managedfusion.com/products/url-rewriter/
You can read more options in this post:
ASP.NET URL Rewriting
As Josh says the essential article is:
http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
Just a note to others who may be having trouble. Make sure to have
<modules runAllManagedModulesForAllRequests="true">
in your web.config
That article is a bit old... and there are better approaches in the .NET framework now. What's funny is I used to do exactly what you are doing (hijacking the Error handler).
http://www.singingeels.com/Blogs/Nullable/2007/09/14/URL_ReWriting_The_Right_Way_Its_Easy.aspx
That's what I think you want to be doing now. Oh, and about performance... that adds about 0.00001 seconds to your page time.
Scott Guthrie's article is a good one, but I am curious as to why you are choosing to do this via the Global.asax instead of using an HttpModule as he suggests. Also, the Asp.Net page lifecycle runs through each and every one of those events in the Global.asax anyway.
HttpModule events run every single request and as long as you are not doing anything crazy in your logic, then you should be good to go. Even database lookups in the Application_BeginRequest method can be mitigated by proper caching.
And when in doubt, write some information out to the Trace in order to find out exactly how long your routine takes. I think you will find that compared to your most expensive operations (database lookups), the time will be negligible.