why some thing like this
url="http:/"+"www.pathname.com"+"/"+"anotherString";
turns into http://www.pathname.com/anotherString.
Notice the // after the http:.
I am not sure what you mean exactly, but if it is in the URL bar of the web-browser, then it is just correcting you. you are meant to have the two forward slashes their. Its just the way you are meant to do it.
An interesting anecdote: Nokia older phones write http:/ instead of http://.
Its just the way urls are designed, and the way browsers interpret them. For more details see this blog post
Double slash in Web addresses 'a bit of a mistake' and
Berners-Lee 'sorry' for slashes
As a string in your file, it does not add an extra / to it, but if you type that string into the browser address bar, the browser will automatically add the additional / to the URL to make it valid. I do believe it will do this for images and other links on the page to make them valid.
Related
I have several html A tag generated programmatically in ASP.NET with a JavaScript function taking long parameter in href. One of those has over 20K characters when it get assigned in backend, but I am seeing the actual link has only 5239 characters on the browser side and the JavaScript function does not have closing. So the link never works. I am thinking about workarounds for this implementation since it's not a good idea to put this much amount of data in links, but now I'm just curious about cause of the issue.
Examples of the code assigning values to the link:
HtmlAnchor.HRef = "javascript:doSomething('Import','" + strHeader_LineIds + "');"
In this case the variable strHeader_LineIds carries a string over 20k characters.
Example of what I'm actually seeing in client side:
<a id=anchor1 class=class1 href="javascript:doSomething('Import', 'blahblahblahblah....">Link Text</a>
Please note the javascript function has no closing here. But when I'm debugging in backend I do see the closing of the function.
I guess this issue may have something to do with the browser's URL limit? I am using IE and I learned IE has a maximum URL length limit as 2,083 characters from Here. But how can the link show up with 5,239 characters?
I've had a similar issue with javascript like dynamic functions created in code and then called. I found that I had to play with swapping out single quotes in the javascript function with double quotes or escaping the quotes.
Then again just reading your post could be a limit issue.
Have you tried assigning the long to an element in the background and then referencing that as part of the javacript. I know IE gets funny with spaces in passed in parameters.
I think found an answer to the issue though. According to This Article:
JavaScript URIs
The JavaScript protocol is used for bookmarklets (aka favlets), a lightweight form of extensibility that permits a user to click a button and run some stored JavaScript on the currently loaded page. In IE9, the team did some work to relax the length limit (from ~260 characters, if I recall correctly) to something significantly larger (~5kb, if I recall correctly).
So I just hit the ~5kb limit.
So i am using the jQuery UI library to open new dialog windows, when the new dialog windows are opened I am passing some parameters like this
open modal
The site works fine and no issues at all, my custompage.html just picks up those values that were passed and they are being used on the page, something like this:
var a = customfunctionget(param1); var b = customfunctionget(param2)....
I just received a report that we are vulnerable to Cross-Site Scripting attacks by replacing any of the params with something like this:
><script>alert(123)</script><param
Which I understand correctly what is supposed to happen but on any browser that I try to inject the script the alert is never displayed so the "script/injection" is not being processed, the custompage.html stops working as expected since we need the values to be entered correctly but there is nothing I can do on that respect.
Is there a magic pill that I am missing here? Most of the XSS information that I find does the same thing, try to inject an alert through a tag but other than me denying to display any content if the parameter is not well formed I dont know what else can be done.
Any recommendations, tutorials welcome.
One of the easiest things you can encode all <, >, and & characters with <, >, and &, respectively. Whenever a browser sees a <something> it thinks its a dom element. If you encode those characters, the browser will actually display them. This will foil people trying to execute <script>badstuff</script> on your site.
Note that people won't be able to do things like add <b> tags to things if you do this.
The above suggestion is a first step, but is by no means exhaustive.
I just found this, which seems like a good guide.
There is encodeURIComponent() function in Javascripts to encode special characters to avoid inserting scripts
I have a search query from the user and I want to process it before applying to browser. since I'm using SEO with htaccess and the search url looks like this : /search/[user query] I should do something to prevent user from doing naughty things.. :) Like searching ../include/conf.php which will result in giving away my configuration file. I want to process the query like removing spaces, removing dots(which will cause problems), commas,etc.
var q = document.getElementById('q').value;
var q = q.replace(/ /gi,"+");
var q = q.replace(/../gi,"");
document.location='search/'+q;
the first replace works just fine but the second one messes with my query.. any solution to replacing this risky characters safely?
So if I disable JavaScript or use curl I still can do "naughty things"? On the client side do the sanity escaping with:
encodeURIComponent(document.getElementById('q').value)
and leave security checks to the server. You would be amazed what malicious user can do (using some escape sequences instead of plain . is the simplest example).
I'd do this server-side - it's too easy for someone to alter your JS in the page or switch it off altogether. Your search script that runs server-side can't (as) easily be tampered with and can then filter the search consistently.
You might also want to restrict what the search returns... if it's able to show sensitive config files, your search may have a little too much reach.
Dots in regular expressions match anything. You need to escape them with a back-slash ('\'):
var q = q.replace(/\.\./gi,"");
The SO post below is comprehensive, but all three methods described fail to encode for periods.
Post: Encode URL in JavaScript?
For instance, if I run the three methods (i.e., escape, encodeURI, encodeURIComponent), none of them encode periods.
So "food.store" comes out as "food.store," which breaks the URL. It breaks the URL because the Rails app cannot recognize the URL as valid and displays the 404 error page. Perhaps it's a configuration mistake in the Rails routes file?
What's the best way to encode periods with Javascript for URLs?
I know this is an old thread, but I didn't see anywhere here any examples of URLs that were causing the original problem. I encountered a similar problem myself a couple of days ago with a Java application. In my case, the string with the period was at the end of the path element of the URL eg.
http://myserver.com/app/servlet/test.string
In this case, the Spring library I'm using was only passing me the 'test' part of that string to the relevant annotated method parameter of my controller class, presumably because it was treating the '.string' as a file extension and stripping it away. Perhaps this is the same underlying issue with the original problem above?
Anyway, I was able to workaround this simply by adding a trailing slash to the URL. Just throwing this out there in case it is useful to anybody else.
John
Periods shouldn't break the url, but I don't know how you are using the period, so I can't really say. None of the functions I know of encode the '.' for a url, meaning you will have to use your own function to encode the '.' .
You could base64 encode the data, but I don't believe there is a native way to do that in js. You could also replace all periods with their ASCII equivalent (%2E) on both the client and server side.
Basically, it's not generally necessary to encode '.', so if you need to do it, you'll need to come up with your own solution. You may want to also do further testing to be sure the '.' will actually break the url.
hth
I had this same problem where my .htaccess was breaking input values with .
Since I did not want to change what the .htaccess was doing I used this to fix it:
var val="foo.bar";
var safevalue=encodeURIComponent(val).replace(/\./g, '%2E');
this does all the standard encoding then replaces . with there ascii equivalent %2E. PHP automatically converts back to . in the $_REQUEST value but the .htaccess doesn't see it as a period so things are all good.
Periods do not have to be encoded in URLs. Here is the RFC to look at.
If a period is "breaking" something, it may be that your server is making its own interpretation of the URL, which is a fine thing to do of course but it means that you have to come up with some encoding scheme of your own when your own metacharacters need escaping.
I had the same question and maybe my solution can help someone else in the future.
In my case the url was generated using javascript. Periods are used to separate values in the url (sling selectors), so the selectors themselves weren't allowed to have periods.
My solution was to replace all periods with the html entity as is Figure 1:
Figure 1: Solution
var urlPart = 'foo.bar';
var safeUrlPart = encodeURIComponent(urlPart.replace(/\./g, '.'));
console.log(safeUrlPart); // foo%26%2346%3Bbar
console.log(decodeURIComponent(safeUrlPart)); // foo.bar
I had problems with .s in rest api urls. It is the fact that they are interpreted as extensions which in it's own way makes sense. Escaping doesn't help because they are unescaped before the call (as already noted). Adding a trailing / didn't help either. I got around this by passing the value as a named argument instead. e.g. api/Id/Text.string to api/Id?arg=Text.string. You'll need to modify the routing on the controller but the handler itself can stay the same.
If its possible using a .htaccess file would make it really cool and easy. Just add a \ before the period. Something like:\.
It is a rails problem, see Rails REST routing: dots in the resource item ID for an explanation (and Rails routing guide, Sec. 3.2)
You shouldn't be using encodeURI() or encodeURIComponent() anyway.
console.log(encodeURIComponent('%^&*'));
Input: %^&*. Output: %25%5E%26*. So, to be clear, this doesn't convert *. Hopefully you know this before you run rm * after "cleansing" that input server-side!
Luckily, MDN gave us a work-around to fix this glaring problem, fixedEncodeURI() and fixedEncodeURIComponent(), which is based on this regex: [!'()*]. (Source: MDN Web Docs: encodeURIComponent().) Just rewrite it to add in a period and you'll be fine:
function fixedEncodeURIComponent(str) {
return encodeURIComponent(str).replace(/[\.!'()*]/g, function(c) {
return '%' + c.charCodeAt(0).toString(16);
});
}
console.log(fixedEncodeURIComponent('hello.'));
I have a Javascript bookmarklet that, when clicked on, redirects the user to a new webpage and supplies the URL of the old webpage as a parameter in the query string.
I'm running into a problem when the original webpage has a double hyphen in the URL (ex. page--1--of--3.html). Stupid, I know - I can't control the original page The javascript escape function I'm using does not escape the hyphen, and IIS 6 gives a file not found error if asked to serve resource.aspx?original=page--1--of--3.html
Is there an alternative javascript escape function I can use? What is the best way to solve this problem? Does anybody know why IIS chokes on resource.aspx?original=page--1 and not page-1?
"escape" and "unescape" are deprecated precisely because it doesn't encode all the relevant characters. DO NOT USE ESCAPE OR UNESCAPE. use "encodeURIComponent" and "decodeURIComponent" instead. Supported in all but the oldest most decrepit browsers. It's really a huge shame this knowledge isn't much more common.
(see also encodeURI and decodeURI)
edit: err just tested, but this doesn't really cover the double hyphens still. Sorry.
Can you expand the escape function with some custom logic to encode the hypen's manually?
resource.aspx?original=page%2d%2d1%2d%2dof%2d%2d3.html
Something like this:
function customEscape(url) {
url = escape(url);
url = url.replace(/-/g, '%2d');
return url;
}
location.href = customEscape("resource.axd?original=test--page.html");
Update, for a bookmarklet:
Link
You're doing something else wrong. -- is legal in URLs and filenames. Maybe the file really isn't found?
-- is used to comment out text in a few scripting languages. SQL Server uses it to add comments. Do you use any database logic to store those filenames? Or create any queries where this name is part of the query string instead of using query parameters?