I am testing for XSS, I add some JavaScript code in the URL and suddenly all the pictures and style of the page disappear, displaying just the text content, and the injected JavaScript command even doesn't get executed, does what happens mean my code is vulnerable to this type of XSS?
The URL is:
http://localhost/index.php/<script>alert('hacked');</script>
No. This has nothing to do with XSS (that the script is not being executed is a good clue to that!).
What is means is that http://localhost/index.php/<script>alert('hacked');</ is a different "directory" to http://localhost/index.php/ or http://localhost/.
You have relative URLs in your document and they don't start with a / so they are relative to the URL of the page.
Since you are accessing the page from a URL that points to a different directory, the links have broken.
For a better understanding about CrossSite Scripting and how to replicate and prevent it, I recommend you the OWASP site, which also includes documentation about other common web vulnerabilities.
The URL is: http://localhost/index.php/script alert('hacked');script
Also, is not helpful to post an URL pointing to your localhost, since that site is in your machine and not on the internet, so we cannot access it and test it. If that same site is also published on the internet, post it with its public IP or its domain.
I dropped the <> of the script tag here as it is filtered
To post source code of any language in a question, format it with the Code format (the brackets button, in the format toolbar).
<script>Example of source code with script tag</script>
Related
I was wondering whatever there is way to check in JavaScript that the website was loaded fully securely, and that it was not modified on user's site (for example by malicious addon)
I found that often such malicious addons are breaking SSL by adding adverts or other malicious scripts, therefore I am wondering how could I detect mixed content warning such as displayed on this image:
(the image taken from https://www.ssl2buy.com/wiki/fix-mixed-content-nonsecure-items-error-on-ssl-secure-site )
I have found the following questions, however I believe that those questions do not fully answer my question:
How can I use JavaScript on the client side to detect if the page was encrypted?
How do I determine whether a page is secure via JavaScript?
My question is how to detect if website was loaded insecurely (or modified at user's end), even if protocol used was https://
side note: I know that such script could be easily deleted by an addon that adds the malicious scripts/adverts/etc., however I prefer to have additional layer of security.
I was wondering whatever there is way to check in JavaScript that the
website was loaded fully securely
Well assuming a malicious addon is able to manipulate your DOM content I belive you can't.
You can however check whether the page was loaded fully encrypted.
One approach for doing so is to check the protocol of A) the current URL and B) all href and src attributes in your DOM.
But this cannot proof that your page was loaded fully securely. It may only confirm that all loaded content on your site was encrypted, but an attacker can (and they actually do) get a TLS/SSL certificate (e.g. using letsencrypt) and simply distributes its malicious code using HTTPS.
Furthermore, you would have to check your DOM for iFrames which might also be able to execute malicious code.
The only thing you could do that might addresses the issue is to check all hrefs & src as mentioned above and additionally compare them against a whitelist.
Eventually as you already mentioned, your script can be easily blocked by the malicious addon. Therefore, I am not convinced such a script is worth the time.
It looks like AJAX is indeed unable (at least for all practical purposes) to write foreign HTML to the current page. But what if your CDN website had, say, a JS that would simply document.write() everything? Then your HTML document would have nothing but a remote script.
<html>
<script src="https://pastebin.com/raw.php?i=0wm5v7i6">
</script>
</html>
I tried this. Funny thing is, sometimes it works and other times it does a kind of security error:
Why doesn't this work? What if, on your own website, you simply put everything on an easy host like Google Drive?
What if, on your own website, you simply put everything on an easy host like Google Drive?
That is possible, unless
You want control over your website and don't want to depend on the security and availibility of another site, or that somebody reports your pastebin as abuse and it gets deleted.
You want to make proper use of security features like content security policy and don't want to allow everything from pastebin.com.
You want search engines to find you. Although at least google does limited interpretation of JavaScript I doubt that they will handle this content the way you like.
From the looks of it, PasteBin doesn't supply content over SSL (https). You've put https in the URL to your script, but PasteBin just redirects this request to http, and the net effect is that you are trying to access a script over http when the page is accessed over https, and Chrome prevents that.
Just try going to https://pastebin.com/raw.php?i=0wm5v7i6: your browser will be redirected to http://pastebin.com/raw.php?i=0wm5v7i6.
I'm trying to build a sample bookmarklet to grab current webpage source code and pass it to a validator. Validator is not a an online website, but a folder with bunch of javascript and html files. I'm trying to open file:///C:/Users/Electrifyings/Desktop/Validator/Main.html file with the help of javascript bookmarklet code and put the source code in the textarea in the newly opened window, but it is not working for some reasons that I'm not aware of.
Here is the sample code with algorithm:
javascript:(function(){var t = document.body.innerHTML;window.open('file:///C:/Users/RandomHero/Desktop/test.html',_self);document.getElementById("validator_textarea")=t;})()
Here are the steps:
Grab current web page source code in a variable.
Open locally stored HTML web page in current or new window or new tab (either way is fine with me, but no luck)
Put the source code from the variable into the validator textarea of the newly opened HTML file.
I have tried above code with a lot of variations, but got stuck on the part where it opens the new window. Either it's not opening the new window at all or it is opening blank window without loading the file.
Would love to get some help with this issue, thanks a lot.
Oh and btw,
Windows 7 x64, Tried IE, Firefox and Chrome. All latest and stable builds. I guess it's not a browser side issues, but something related to javascript code not opening the URI with file:/// protocol. Let me know if any more details are needed. :)
You wouldn't want a webpage you visit to be able to open up file://c:/Program Files/Quicken/YourSensitiveTaxInfo right? Because then if you make a mistake and go to a "bad" website (either a sleazy one or a good one that's been compromised by hackers), evil people on the intarweb would suddenly have access to your private info. That would suck.
Browser makers know this, and for that reason they put VERY strict limits to prevent Javascript code from accessing files on a user's local computer. This is what is getting in the way of your plan.
Solutions?
build the whole validator in to the bookmarklet (not likely to work unless it's really small)
put your validator code up on the web somewhere
write a plug-in (because the user has to choose to install a plug-in, they get much more freedom than webpages ... even though for Firefox, Chrome, etc. plug-ins are basically just Javascript)
* * Edit * *
Extra bonus solution, if you don't limit yourself to a purely-client-side implementation:
Have your bookmarklet add a normal (HTML) form to the page.
Also add an iframe to the page (it's ok if you hide it with CSS styling)
Set the form's target attribute to point to the iframe. This will make it so that, when the user submits the form and the server replies back to that submission, the server's reply will go to the (hidden) iframe, instead of replacing the page as it normally would.
Add a file input to your form - you won't be able to access the file within that input using Javascript, but that's ok because your server will be doing the accessing, not your bookmarklet.
Write a server-side script which takes the form submissions, reads the file that came with it, and then parrots that file back as the response. In other words, you'll have a URL that you can POST to, and when it sees a file in the POST's contents, it will respond back with the contents of that file.
Now that you've got all that the user can pick their validator file using the file input, upload it to your server, your server will respond back with the file it just got, and that file will appear as the contents of the iframe.
And now that you finally have the file that you worked so hard to get (inside your iframe) you can do $('#thatIframe').html() and viola, you have access to your file. You can save the current page's source and then replace the whole page with that uploaded file (and then pass the saved page source back to the new validator page), or you can do whatever else you want with the contents of the uploaded validator file.
Of course, if the file doesn't vary from computer to computer, you can make all of that much simpler by just having a server that sends the validator file back; this could be a pure Apache server with no logic whatsoever, as all it would have to do is serve a static file.
Either way though, if you go with this approach and your new file upload script is not on the same server as your starting webpage, you will have a new security problem: cross-domain script limitations. However, these limitations are much less strict than local file access ones, so there are ways to work around them (JSONP, cross-site policy files, etc.). There are already tons of great Stack Overflow posts explaining these techniques, so I won't bother repeating them here.
Hope that helps.
we have a site with Iframes pointing to dynamic Urls (by user input).
In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Is there any solution for this?
Any other suggestions?
Thanks,
Tal
we have a site with Iframes pointing to dynamic Urls (by user input). In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
So it sounds like you are making a sort of "browser in a web page."
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
Yes, except not many things have onerror events. I assume you are aware of this from your comments on other answers. If I understand you right, you're talking about using a dummy script element to load the URL first (as a script, even though it's not really a script), and determine whether the URL is valid using the using onload/onerror handlers for the script element (onerror will not fire on a script error, only a network error).
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Your assumption is correct. If the URL actually does contain a script, it will execute in the user's browser in the same domain as your site.
Is there any solution for this?
A simple workaround might be to do something like what jsfiddle.net does... have a separate subdomain act as a "firewall" between the third-party content and your real domain.
Any other suggestions?
The script preload hack is really just that, a hack. It misappropriates the script tag and makes needless requests. I would probably look into using XHR to fire off a HEAD request instead, or doing some light server-side proxying.
Yes, if you use a <script> tag to embed a remote JS file, you have a security problem as the code is going to be executed in the context of your page.
The only workaround idea that comes to mind is making a server-side request to the resource and parse the response headers. This however may behave differently from a client-side request, as the call will be coming from the server, so it'll have a different IP, different cookies, etc.
If the user can only specify the frame’s URL, then any scripting in the frame’s document would be run in the context of the frame’s document and not in the context of the parent document the frame is embedded.
The question whether a script running inside the frame can access the parent’s document (i. e. your document) depends on the origin of both documents: only if they are equal both document’s are said to be same origin. And only in that case one document can access the other document.
I don't think this is possible, but it never hurts to ask.
Is there any way for me to host a file (or folder) on someone else's domain (with their permission, of course)? For example, if their site is hosted at www.example.com, I would like to host a file at www.example.com/foo.html, or a folder at www.example.com/foo/, or the like. I just need to be able to make changes at will to a single file.
We can't use a redirect or anything like that - the purpose of this is to allow me to control a document loaded in an <iframe> on their site, and for the JavaScript in that <iframe> to have access (i.e., no security restrictions) to its parent page - which is only allowed if the domains match. Their site doesn't change the document.domain property to relax the security restrictions, nor can we ask them to start using that approach (it's an enormous site).
I also can't generate an <iframe> and create its document solely using JavaScript - we've done that in the past, and it gets around the security restrictions (the generated <iframe> is in the same domain as its parent page), but it causes other issues and difficulties that add up to a deal-breaker in this case.
Please let me know if you have any alternative suggestions, or if you need any more information about what exactly I'm trying to do.
Thanks in advance for any help!
I hope I'm understanding this correctly. Since you have their permission to host a file on their site, can you just use FTP? They can set you up to only be able to drop files in one directory on their site, and you can edit the file there.
Provide embed code to the other party to load remote javascript file to their page. You may then generate content or information gathering. As the javascript file is hosted on your side, it's under your control. A Visitor Counter is a similar case.
You could make a php script that loads it's data from your own site.
this should work actually:
<?php echo file_get_contents("http://www.yoursite.com/yourfile.html"); ?>
Edit: You might be able to do the same with javascript, but i don't know the code for it... Sorry. :-/
Sounds like your friend can set up a reverse proxy rule on their web server for your file. http://httpd.apache.org/docs/2.0/mod/mod_proxy.html