Anyone know how to prevent this IIS7.5 /aux path issue (work on IIS8). this is not a real 404 error !?! ex http://msdn.microsoft.com/aux
This is due to some built-in restrictions on URLs in IIS, which do not allow you to use names that have special meanings in the Windows file system, dating back all the way to the days of CP/M:
https://www.bitquabit.com/post/zombie-operating-systems-and-aspnet-mvc/
If you are using ASP.NET version 4 or later, you can use this setting in web.config to disable these URL restrictions:
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
<!-- ... your other settings ... -->
</system.web>
</configuration>
This should be safe if you are sure there are is no direct mapping between parts of URLs and file system paths being done anywhere, in the web server, the framework or your own code and any third-party dependencies. This should usually be the case in a modern web application, but don't take my (or anyone's) word for it, unless they have solid proof, which I cannot provide here.
See also: http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx
If you are dealing with problems like this, it may mean that your application uses arbitrary text in the URL path that may be originally user input. This is a misguided design pattern used in so-called "REST" APIs in order to make URLs "pretty". You will probably also run into issues with percent-encoding, Unicode characters, trans-BNP Unicode characters (emoji!), Unicode normalization, case-insensitivity (along with the Turkish-i and Greek-something problem) and countless issues that are yet to be discovered.
REST is not about pretty URLs, and pretty URLs do not need to contain arbitrary text (and unless you are Wikipedia, you will have a hard time getting it right). Pretty URLs improving your Google ranking is controversial at best, if not a myth.
Here are some suggestions to redesign the URLs in your application:
Use unique IDs instead of names. Human-readable names should never be used as identifiers ever.
If you think you have to decorate your URLs with text (in addition to a unique ID), then "sanitize" the text part. For example, you can remove any non-ASCII characters and any characters with special meanings in URLs, whitespaces, etc., and replace sequences of disallowed characters with dashes. And of course, also replace the "forbidden" names such as aux. But, seriously, don't bother with "prettifying" URLs like this.
If it makes sense for your application, let the user specify the URL fragment, but use validation to limit what URLs are allowed. You can then enforce the fragment to be unique and use it as a unique ID, rather than just decoration.
If aux is a fixed part of your URLs, just replace it with something else.
Use query strings or POST requests for arbitrary user input. And of course, validate and sanitize it. Something like a search string should not be in the URL path.
If you disagree, or you have no choice in the matter, or no time to redesign your API, see https://stackoverflow.com/a/14771755/2279059
Related
I'm setting up a web environment where users can create links but they can only modify the href attribute, not type in the <a> tag themselves.
So basically any href value is allowed; http/ftp/mailto/whatever.
Are there any XSS or other risks for my site if I leave the href attribute open like this? If yes, what would they be and how should I handle them?
There are URL schemes, such as javascript: or possibly data:, that could, in themselves, serve as XSS vectors if the user is tricked into clicking them. You should maintain a whitelist of known, safe URL schemes (like http, https, ftp, etc.) and disallow any URLs that don't begin with such a scheme.
Note that simply blacklisting known dangerous URL schemes is not a safe approach, since you cannot possibly know all the schemes that might be used as attack vectors (as this may depend on things like what third-party software the user has installed). In particular, keep in mind that URL schemes are supposed to be case-insensitive; a naïve blacklisting implementation that simply disallowed URLs beginning with javascript: might be trivially bypassed with a jAvAsCrIpT: URL.
(You could allow schemeless relative URLs if you wanted, but if so, make sure that you parse them conservatively and according to the standard, so that an attacker can't possibly disguise a harmful absolute URL as a relative one. In particular, I would recommend that any URL that includes a colon (:) before the first slash (/), if any, be treated as an absolute URL subject to whitelisting. Just to be sure, you may also want to prepend the string "./" to any relative URLs that don't already begin with "/" or "./" in order to eliminate any potential parsing ambiguity.)
The other thing you need to ensure is that you properly HTML-escape any strings, including URLs (especially user-supplied ones), that will be embedded in HTML attributes. In particular, any & characters will need to be replaced with the & character entity, and (for double-quoted attributes) any " characters with ". Replacing < with < and ' with ' may also be a good idea, and the safest approach may be to actually replace any characters (other than known safe ones, like alphanumerics) with their corresponding HTML character entities. In any case, you programming language probably has a standard function or library to do this (e.g. htmlspecialchars() in PHP).
Ps. See also the OWASP XSS Filter Evasion Cheat Sheet for some examples of possible attacks that your implementation should be able to resist.
You must ensure that the href value will be a valid URL. If you would not escaped user input it would make mySQL injection attacks possible.
also the user could enter javascript:
Javascript will close the browser window on click
I was wondering what would be the best way to achieve a multi-language template based website. So say I want to offer my website in Englisch and German there are some different methods. My interest is mainly about SEO, so which would be the best way for search engines.
The first way that I often see is using different directories for each language, for example www.example.com for English and www.example.com/de/ for the German translation. The disadvantage of this is: when changing a file, ist has to be changed in every directory manually. And for search engines the two directories would be concerned as duplicate content, wouldnt they?
The second way I know is just using some GET value like www.example.com?lang=de and then setting a cookie. But this way search engines probably wont even find the different languages.
So is there another way or which one is the best?
I worked on internationalised websites until this year. The advice we always had from SEO gurus was to discriminate language based on URL - so, www.example.com/en and www.example.com/de.
I think this is also better for users; if i bookmark a page in German, then when i come back to it, i get a page in German even if my cookies have expired. Similarly, i can do things like post the URL on Facebook, and have my German-speaking friends click on it and get a site in German.
Note that if your site serves multiple countries, you should handle those along with language - so, you might have example.com/de-DE, example.com/en-GB, example.com/en-IE, etc.
However, this should not involve duplication. Instead, you should set your application up to process the URL, extract the locale information, and then forward the request internally to a locale-independent page. So, a request for example.com/de-DE/info and a request for example.com/en-IE/info should both be passed to /info.jsp (or i'm guessing info.php in your case). That page should then be coded to emit text in the appropriate language, using a page-level localisation mechanism.
Things are a bit trickier if you want the URLs themselves to be localised (eg example.org/de-DE/anmelden vs example.org/en-IE/sign-in). However, the same principle applies: extract the locale, then forward to a common page. The difference is that there must be more sophistication in figuring out what the page is from the URL; you will need a mapping from natural language in the URL to the page filename.
If a web application allows users to contribute translation messages in order to localize the application to a given language or locale, then what are the potential security risks involved in this. [Apart from social engineering which is an obvious one]
These translation messages are usually a collection of key-value pairs in some kind of format depending on the language/library etc. For example, PHP array files as in many OSS PHP applications, getetxt .po files for apps using gettext, Yaml files in Rails, and many others.
Such translation data is then used to provide a new locale in the list of locales available for a site.
As soon as you relinquish control of the content, you are effectively allowing any "authorized" content provider to add whatever they want to your UI. Even if you prevent execution of potential code included in the content, you cannot prevent display of inappropriate text (or images) to users unless you screen that text at its entry point into your system.
One way to address this is via service contracts with the content providers that specify their obligations for content verification. Depending on who the providers are, this may be enough to make you confortable with relinquishing control. Otherwise, there's pretty much no substitute for a human with the application's owner organization approving all submitted content before it is approved for publication.
To be honest this is kind of a strange question. I will assume that you have read and understand the OWASP top 10. I assume you know how to protect your own server from attack.
That being said in my mind the most obvious attack against this translation system is persistent XSS which would allow an attacker to deface every website using this dataset. Just saying "oah we htmlencode the values" isn't enough. If you are supplying these data sets to a 3rd party you can't expect all of them to sanitize the data properly. To make matters worse, XSS is an output problem, you can't HTML encode the entire data set and expect it to be 100% safe because you have no idea how the data is going to be used within the HTML document. The problem is the data may end up within a script tag or event, and then the protection from html-encoding could be nullified entirely. I always chuckle when I see someone using strip_tags() to try and stop xss, this is just the wrong approach.
In summation there really isn't a 100% solution to the problem, but this will prevent most xss:
$var=htmlspecialchars($var,ENT_QUOTES,"UTF-8");
$var=rtrim($var,"\\");
Obviously the rtrim() is used to help prevent xss within a script tag. If the string ends with a backslash you can break out of a quoted string, backslashes are equally as dangerous as quote marks.
I think it's safe to say that HTML elements in the "new" string can only be those that were in the old string, minus a few specific attributes such as title and alt.
Example:
English string: <strong title="Just a test">Hover this message</strong>
Dutch translation: <strong title="Gewoon een test">Hang hier met de muis boven</strong> - will be marked as safe
Dutch translation: <strong onmouseover="window.location='something';">Hang hier met de muis boven</strong> will be invalidated by the filter
You would have to write a rather strong filter though, and always verify that no attributes were added, removed, and no HTML elements were added or removed. Also, always be careful with " and '.
I'm wondering what the bare minimum to make a site safe from XSS is.
If I simply replace < with < in all user submitted content, will my site be safe from XSS?
Depends hugely on context.
Also, encoding less than only isn't that flash of an idea. You should just encode all characters which have special meaning and could be used for XSS...
<
>
"
'
&
For a trivial example of where encoding the less than won't matter is something like this...
Welcome to Dodgy Site. Please link to your homepage.
Malicious user enters...
http://www.example.com" onclick="window.location = 'http://nasty.com'; return false;
Which obviously becomes...
View user's website
Had you encoded double quotes, that attack would not be valid.
There are also case where the encoding of the page counts. Ie - if your page character set is not correct or does not match in all applicable spots, then there are potential vulnerabilities. See http://openmya.hacker.jp/hasegawa/security/utf7cs.html for details.
No. You have to escape all user input, regardless of what it contains.
Depending on the framework you are using, many now have an input validation module. A key piece I tell software students when I do lectures is USE THE INPUT VALIDATION MODULES WHICH ALREADY EXIST!
reinventing the wheel is often less effective than using the tried and tested modules which exist already. .Net has most of what you might need built in - really easy to whitelist (where you know the only input allowed) or blacklist (a bit less effective as known 'bad' things always change, but still valuable)
If you escape all user input you should be safe.
That mean EVERYTHING EVERYWHERE it shows up. Even a username on a profile.
I am working on a site that have an international aim; I.o.w., logged in users can add text in their own language. I am hoping for international page names and content.
An URL example, like the Japanese Wikipedia: http://ja.wikipedia.org/wiki/メインページ (Both pagename and content text).
I know by using UTF-8, I can do this, but how should I control it?
UTF-8 contains way to many languages/letters to control in a script, I guess, so how safe/unsafe is it to allow people to add UTF-8 text?
I can see that someone could add harmful code this way, but how to prevent it?
All information regarding safety/control when using UTF-8 is appreciated!
EDIT: PS! I use PHP and MySQL.
Warning: perhaps a slightly rusty response:
Note: not discussing host name (IDNS) issues.
The only completely safe thing here is to use %-escaped UTF-8. Some browsers will display this as what you want, and some will display the %-escapes. (e.g. http://foo.bar/%ee%cc%cf.html)
If you put 'real UTF-8' in the URLs, many things will work, but there may be unpleasant surprises lurking for some people in some browsers. I'm reading your question as dealing with 100% static content. If you are trying to do this with code behind the site, you have additional issues to work on.
The 'unpleasant surprises' would be (a) people finding the %xx's in the URL unreadable, (b) a browser that melts, (c) some data scraping or aggregating application that melts.
I wish I were more up to date on this, but I'm not, so my recommendation is to deploy a test site and then try to access it with everything you can put your hands on, including mobile phones. Persuade Google to index it, and see what happens there.
For domain names, this is called IDN. For page names, you may want to think of the possibility of IDN spoofs.
It's safe as long as you don't interpret it literally as SQL (SQL injection) or HTML (XSS) or any other language. Just escape any user-controlled input (request URL, request headers, request parameters, request body, etc..etc..) at the point it's going to be used in SQL or HTML.
It's unclear what server side programming language you're using, so I can't go further in detail.