We have a fairly complicated ASP.NET MVC project with cross domain login widgets and a lot of semi-legacy code.
There is a system where we login people through an iframe. The url for the iframe we send through a string attached to the MVC Model.
Problem is; on really rare occassions we see malformed query string parameters coming through. It's always the same malformation though. I want to fix the issue, but I can't figure out why this happens.
I'm expecting some Adblocker-type or privacy settings, or maybe some Regional settings, but I have no clue where to start.
I am hoping someone will recognize the pattern and say; that's a localization pattern when your Windows is set on Turkey or whatever, you should check your encoding etc etc.
Anyway here's the example:
Expected:
auth-dialog-window?openerOrigin=https%3a%2f%2f.poules.com&color=C3042E&openerType=iframe
Coming through:
auth-dialog-window?color=P304212R&openerType=vsenzr&openerOrigin=uggcf%3N%2S%2Scbhyrf.pbz
Apparently the order of the query string also changes. Here more closely per parameter:
iframe
vsenzr
https:// poules.com (spaces are for aligning)
uggcf%3N%2S%2Scbhyrf.pbz
C3042E
P304212R
Does anyone recognize the pattern and can give me a hint where I should be looking?
I know for sure the last time it happened with IE 9.0, but can't reproduce it.
ROT-13.
A system somewhere is "trying to crypt" in a very simple way...
Check "pairs" of letters in both values:
abcdefghijklmnopqrstuvwxyzabcdefghijklm
nopqrstuvwxyzabcdefghijklmnopqrstuvwxyz
Related
I have this project where I need to know if a visitor legitimately arrived from a QR code. Document.referrer value from a QR code shows blank. I have looked at some answers suggesting to put parameter in the query string (e.g. ?source=qr), but anyone could easily add the parameter into the URL and my code would believe it is from a QR code (e.g. www.project.com/check.page?source=qr) . I have thought of adding codes to make sure it is from a mobile phone / tablet as secondary way to authenticate but many browsers have add-ons to fool websites.
Any suggestions would be greatly appreciated.
Thanks in advance.
I think the best solution for you is creating your regional QR Codes pointing to:
Region 1) http://example.com/?qr=f61060194c9c6763bb63385782aa216f
Region 2) http://example.com/?qr=731417b947aa548528344fab8e0f29b6
Region 3) http://example.com/?qr=df189e7f7c8b89edd05ccc6aec36c36d
if the value of the parameter qr is anything other than f61060194c9c6763bb63385782aa216f, 731417b947aa548528344fab8e0f29b6 or df189e7f7c8b89edd05ccc6aec36c36d, then you can ignore it and assume the user didn't come from any QR Code.
Of course, any user can remove the source parameter. But at least he can't add a valid one, unless he really had access to the code.
...but anyone could easily add the parameter into the URL and my code would believe it is from a QR code
Well, anyone could also scan the QR code, view the link, and remove the source=qr from it.
Data collection is never 100% reliable. Users can change their browser's user agent, inject cookies with some strange values, open your page through a proxy server, and so on.
You could create your own device or App for scanning the QR-code. If you read the post I've linked, you will see that this is a waste of time and resources.
So, what is left is to make a solution which will work for most of the users. Appending a source=qr parameter to your URL seems to be the simplest solution. You could also link to an entirely different domain and redirect the request, so it would be more fraud-safe. But it will never be 100% accurate.
I have a standard ASP.Net WebForms application running on IIS 7.0 with an Integrated Managed Pipeline. Many of the images on our site have spaces in their files names (e.g. './baseball drawing.gif'). When we place these images into our html pages we url encode the paths so that our html img tags look like this <img src='./baseball%20drawing.gif' />
Now, the problem comes in when certain search engines and webcrawlers try to index our site. When they scrape our pages they will html encode our already html-encoded paths getting image links like this './baseball%2520drawing.gif' where %25 is the url encoding for '%'. This causes two problems:
When users get results from these search engines they receive broken links.
When users attempt to navigate to these broken links it throws errors in our system.
As you can see this is a lose lose situation. Users get broken links, and we get noise in our error logs.
I've been trying to figure out how to correct this problem with no luck. Here is what I've tried:
Set <requestFiltering allowDoubleEscaping='true'> in web.config to prevent the "404.11 URL Double Escaped error". This fixed the first error but caused a new one, "a potentially dangerous Request.Path was found".
Removed the '%' from the <httpRuntime requestPathInvalidChars> to prevent the "potentially dangerous Request.Path" error. This fixed the second error but now we have a third one, "Resource can't be found".
I placed a break in my code to watch Request.Path. It looks like it is right with a value of 'Ball Image.gif' instead of 'Ball%2520Image.gif'. With this being the case I'm not sure why it isn't working.
I feel like I have a super hack where I am having to disable everything without really understanding why nothing is working. So I guess my question is three fold
Why did solution attempt 1 not take care of the problem?
Why did solution 2 not take care of the problem?
Why does my Request.Path look right in step 3 but it still doesn't work?
Any help anyone can provide would be greatly appreciated.
OK, after much searching of the internets and plenty of experimentation I think I finally understand what is going on. My main problem was a case of extreme confirmation bias. Everything I read said what I wanted to hear rather than what it actually said. I am going to summarize greatly the key points I needed to understand in order to answer my question.
First, I needed to understand that IIS and ASP.Net are two different applications. What IIS does in a nutshell is receive a request, route that request to an application that handles it, gets the output from the handling application, and then sends the output from the application back to the requester. What ASP.Net does is receive the request from IIS, handle it, and then pass the response back to IIS. This is a huge over-generalization of the whole process but for my purposes here it is good enough.1
Incoming ASP.Net requests have to pass through two gatekeepers. The IIS7 RequestFiltering module(configured in system.webserver/requestFiltering2), and then the ASP.Net HttpRuntime request filters(configured in system.web/httpRuntime3).
The IIS RequestFiltering module is the only one that normalizes incoming requests and it only applies normalization ONE time. Again I repeat it only applies it ONE time. Even if <requestFiltering allowDoubleEscaping="true" /> it will still only apply normalization once. So that means '%2520' will be normalized to '%20'. At this point if allowDoubleEscaping is false IIS will not let the request through since '%20' could still be normalized. If, however, allowDoubleEscaping is set to true then IIS7 will pass off the request '%20' to the next gatekeeper, ASP.Net. This was the cause of the first error.
The Asp.net filter is where the requestPathInvalidCharacters are checked. So now our '%20' is invalid because by default '%' is a part of requestPathInvalidCharacters. If we remove the '%' from that list we will make it through the second gatekeeper and ASP.Net will try to handle our request. This was the cause of the second error.
Now ASP.net will try to convert our virtual path into a physical one on the server. Unfortunately, we still have a '%20' in our path instead of the ' ' we want so ASP.Net isn't able to find the resource we want and throws a "resource can't be found error". The reason the path looked right to me when I broke in my code is because I placed a watch on the Request.Url property. This property tries to be helpful by applying its own normalization in its ToString() method thus making our %20 look like the ' ' we want even though it isn't. This was the cause of the final error.
To make this work we could write our own custom module that receives the request after the first two gatekeepers and fully normalizes it before handing it off to ASP.Net. Doing this though would allow any character to come through as long as it was URL encoded. For example, we normally don't want to allow a '<' or a '>' in our paths since these can be used to insert tags into our code. As things work right now the < and > will not get past the ASP.Net filter since they are part of the requestPathInvalidCharacters. However, encoded as a %253C and a %253E they can if we open the first two gates and then normalize the request in our own custom module before handing it off to ASP.Net.
In conclusion, allowing %2520 to be fully normalized can't be done without creating a large security hole. If it were possible to tell the RequestFiltering module to fully normalize every request it receives before testing that request against the first two gatekeepers then it would be much safer but right now that functionality isn't available.
If I got anything wrong let me know and I hope this helps somebody.
If you want to allow double-escaping, you can follow the instructions at
http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering
It worked for me on IIS 7.0 with no other configuration required. Double-escaping has no impact for the code of the web site I implemented it on; I don't know what potential security implications there could be for other sites.
It's C# + .net 2.0, but this can be pretty much any environment
I have a list in my website where you can get coming from several different locations (modules). It is a normal list screen, with add/edit (an other) links in it.
You sometimes get here from one module, sometimes from an other module. The only thing that I would like to fix is the Back link. It should always take you back to the module where you came from.
What is the best way to do this?
Session variable (this is so far my best choice, but I am not really happy to use this)
URL. I could transmit a parameter all over, "carry it with me" (i don't like this a lot because of the number of the pages that are related to this list, I would have to carry that variable with me in add, edit and other screens, too many places to change)
cookies ?(limited number of cookies, and things like that, don't really like this one either.)
4-5-6 ?
How are all you guys handling this issue?
Save the referer in Session and redirect them to this from the back link eventhandler.
This assumes you are doing nothing funky with the querystring.
I have concerns myself about using Session to store information but for this scenario, it is perfectly acceptable.
Cookies are another option, but overkill, unless you factor in the possibility of losing session information on website/app-pool recycle
I currently implement a replace function in the page render method which replaces commonly used strings - such as replace [cfe] with the root to the customer front end. This is because the value may be different based on the version of the site - for example the root to the image folder ([imagepath]) is /Images on development and live, but /Test/Images on test.
I have a catalogue of products for which I would like to change [productName] to a link to the catalogue page for that product. I would like to go through the entire page and replace all instances of [someValue] with the relevant link. Currently I do this by looping through all the products in the product database and replacing [productName] with the link to the catalog page for that product. However this is limited to products which exist in the database. "Links" to products which have been removed currently wont be replaced, so [someValue] will be displayed to the user. This does not look good.
So you should be able to see my problem from this. Does anyone know of a way to achieve what I would like to easily? I could use regexes, but I don't have much experience of those. If this is the easiest way, using "For Each Match As String In Regex.Matches(blah, blah)" then I am willing to look further into this.
However at some point I would like to take this further - for example setting page layouts such as 3 columns with an image top right using [layout type="3colImageTopRight" imageURL="imageURL"]Content here[/layout]. I think I could kind of do this now, but I cant figure out how to deal with this if the imageURL were, say, [Image:Product01.gif] (using regex.match("[[a-zA-Z]{0,}]") I think would match just [layout type="3colImageTopRight" imageURL="[Image:Product01.gif] (it would not get to the end of the layout tag). Obviously the above wouldn't quite work, as I haven't included double quotes in the match string or anything, but you get the general idea. You should be able to get the general idea of what I am getting at and what I am trying to do though.
Does anyone have any ideas or pointers which could help me with this? Also if this is not strictly token replacement then please point me to what it is, so I can further develop this.
Aristos - hope reexplaining this resolves the confusion.
Thanks in advance,
Regards,
Richard Clarke
#RichardClarke - I would go with Regular Expressions, they're not as terrible to learn as you might think and with a bit of careful usage will solve your problems.
I've always found this a very useful tool.
http://derekslager.com/blog/posts/2007/09/a-better-dotnet-regular-expression-tester.ashx
goes nicely with a cheat sheet ;-)
http://www.addedbytes.com/cheat-sheets/regular-expressions-cheat-sheet/
Good luck.
We got a long-running website where XSS lurks. The problem comes from that some developers directly - without using HtmlEncode/Decode() - retrieve Request["sth"] to do the process, putting on the web.
I wonder if there is any mechanism like HTTPModule to help us HtmlEncode() all the items in a Http request to avoid XSS to some extent.
Appreciate for any suggestion.
Rgds,
Ricky
The problem is not retrieving Request data without HTML-encoding. In fact that's perfectly correct. You should not encode any text until the final output stage when you spit it into an HTML page.
Trying to blanket-encode incoming parameters, whether that's HTML-encoding or SQL-encoding, is totally the wrong thing. It may hide XSS holes in your app but it does not fix them. You will still have a hole if you output content that hasn't come from parameters, or has been processed since then. Meanwhile the automatic encoding will fill your database with multiply-escaped &amp;amp;amp;amp;amp; crud.
You need to fix the output stage, that's where the problem lies.
Like bobince said, this is an output problem, not an input problem. If you can isolate where this data is being output on the page, you could create a Filter and add it to the Response object. This filter would isolate the areas that are common output and then HtmlEncode them.