I have HTML and JavaScript files on my filesystem for a mobile application that is in development. When the application is deployed to a mobile device, these files will be hosted on the local filesystem there, where XSS from file:// is not an issue. An important part of this application is sending XHR POST requests to a RESTful API.
It seems like XSS should not be a security issue for browsers if the files making the request are hosted on a local filesystem instead of deployed to a web server.
Does anyone know of a browser extension or configuration change that will enable XSS from files hosted on a local file system?
Well, although you will have to change the server and client code a little bit, it isn't very clean and you will have to trust the server, you can load the data as a javascript which contains a call to a function in your page and a big string or so as the parameter. This seems to be a good example.
Alternatively, you could serve the files from a local webserver and fiddle around with the hostsfile and document.domain.
I've found a useful link that's helped me execute POST requests from localhost to another domain. It is a Firefox hack that allows XSS from files hosted at localhost. It's not perfect, but it helps me get this thing developed.
Related
I have a website hosted in ISS (can be other) that loads when it's called on localhost but not from extern :) like: http://:8081/Website.html.
The verification whether the website is called from localhost it's on the client in a js script that I can’t modify as it’s encrypted.
So I was thinking at two options:
Develop an ASP application that has a remote desktop connection to the machine that host the website (not some many example on how to).
Maybe configure the IIS configuration (didn't found how)
I'm out of ideas
Do you have any other solution or can you point on how can I do one of the above?
I have tried the WinForm solution from here: https://www.codeproject.com/kb/cs/remotedesktop_csharpnet.aspx and it doesn't work. And I prefer a website.
Updates:
The only working solution that I have for now is to configure a Remote Desktop Services (Web Access) as I hosted the application on Server 2008 R2. Then I only shared the browser that has the localhost page as default page
The javascript files are all minified and encrypted, meaning that if I search localhost as a word in all the files, nothing shows up. So fixing the client will be hard.
Is it possible to create a new Site Binding on IIS and access the site using the binding hostname? This requires your network DNS to register the hostname to the IP Address.
I assume you are dealing with encrypted(???) javascript that is hardcoded to display DOM only if it is loaded from localhost.
If by encrypted you mean minified you should still be able to find reference to "localhost" and modify javascript in minified version. If it is really encrypted by a wrapper of third party javascript library then I would suggest you to rewrite javascript. I mean how can there be any quality code in javascript code that is hardcoded to load only from localhost?
Fix the client and stop exploring other solutions like remote desktop connection. None of them are practical and sustainable solutions.
I think you need to use WebRTC, but it's supported for Chrome and Firefox. It allows two users to communicate directly, browser to browser using the RTCPeerConnection API.
What is the fundamental difference running a file using a server in localhost, and opening a file such as file:///Users/$user_name/$your_directory/index.html, assuming no backend is used, and it is only frontend and contains html/css/js
How does this also affect interactions with other server ie. ajax requests?
I am sorry if this is too broad, but I haven't found a solid answer to these underlying questions.
Fundamentally, assuming at some point you're going to host the result on an actual web server, the former matches the target environment while the latter doesn't. Browsers treat local files and files served from web servers (even localhost web servers) differently, although very similarly. One aspect of this is the encoding: When you retrieve a file from a web server, the process of determine what encoding the data is in is different from opening a local file.
How does this also affect interactions with other server ie. ajax requests?
This is one of the primary ways in which they're handled differently, and it even varies from browser to browser. A page loaded from a file:// URL has origin null from a Same Origin Policy standpoint. Some browsers (like Chrome) disallow Cross-Origin Resource Sharing entirely for origin null, even when the server you're trying to talk to has a wide-open CORS policy (*). Others (like Firefox) allow origin null to match the wildcard.
In general, for best results, ensure that your development environment matches your deployment environment in the important ways. That means doing your development using a web server process rather than local files. Most IDEs will happily provide that process for you; if not, Apache or Nginx aren't hard to install.
answer is simple,
if u don't have made active backend yet for "index.html" then it would not effect.e.g.-"localhost" and "index.html" will be same this time.
but when u start working with the backend,then most of the backend processes need an active server (need localhost).
e.g.-
1.
fetch('local.json')... //fetch json or any file would not work for local files.
2.
u may not ineract with mysql/django etc. databases.
means it cause errors in signup/login , store any image/video/docs at database etc.
so better is work in localhost, it's most easy way is :-
VScode(IDE) >> extenctions >> live server (just need to click a button to make
localhost and click again to stop localhost)
https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
It won't make any difference, I think.
But there is an exception when using Chrome! Sometimes I have seen if a html file is added with some CDN link, then it doesn't loaded into html specifically in Chrome but if you try the same file in Firefox or Internet Explorer, it works.
I have faced this problem and hence I always put it under local IIS default website.
I now this is probably a dumb question, but I'm new to web development and I need to clarify this: to interact with Firebase, my code needs to be in a web server or a CDN, right? I can only test if the connection between Firebase and my files if they are online?
Thanks.
You can build and test Firebase apps without putting the files online anywhere. You can simply create a test.html on your local filesystem and open it in a browser (i.e. as a file://.../test.html url) and Firebase will work 100% fine.
Note that if you want to use Firebase Simple Login (for facebook/twitter/github/email+password auth), the files do have to be served by a web server. You can still do this locally though. You just have to spin up a local web server. This can be as easy as "python -mSimpleHTTPServer" if you're on a unix-like OS (linux, OSX, etc.). Then point your browser at http://localhost:8000/test.html or whatever.
You don't need to put the files online until you actually want to deploy your app and have other people use it.
Your server-side code will need to be on a server to execute, but that server doesn't need to be online. Try a local server like XAMPP or a bitnami stack
I have two websites in IIS7 (WS2008) that points to the exact same folder on my server. The standard website (http://example.com) uses a normal HTTP protocol. However I have issued a SSL certificate to a subdomain (https://ssl.example.com) on the other website and it's on this protocol I'm having troubles.
On the HTTPS website some of my files just return empty or "nothing". Take for example my general CSS or JavaScript files. They work fine on my HTTP website, but on the HTTPS website they are just empty.
Am I missing a configuration in the IIS or am I just stupid? What am I missing here?
I just had an analog situation that might pertain to yours. In our case the server has .gz (compressed) versions of html and js and these were empty due to the way the build was deployed. It might also happen that your web server is not configured to serve the .gz files up to the client with the correct file type in HTTP.
We have a large number of people (10k+) who return to my clients' sites on a regular basis to use a web app we built, improve, and host for them. We have been making fairly frequent backward-incompatible updates to the web app's javascript as our app has improved and evolved. During deployments, the javascript is minified and concatenated into one file, loaded in the browser by require.js, and is uploaded to and hosted on Amazon S3. The file name & url currently doesn't change at all during updates. This last week we deployed a major refactor to the web app and got a few (but not a lot) of reports back that the app stopped working for some people, particularly in firefox. It seemed like a caching issue. We were able to see it initially in a few browsers in testing but it seemed to go away after a refresh or two.
It dawned on me that I really don't know what browser-caching ramifications deploying a new version of a javascript file (with the same name) on S3 will have and whether this situation warrants cache-busting or manipulating S3's headers or anything. Can someone help me get a handle on this? Are there actions I should be taking during deployments to ensure that browsers will immediately get the new version of a javascript file? If not, we run the risk of the javascript and the server API being out of sync and failing, which I think happened here.
Not sure if it matters, but the site's server runs Django and the app and DB are deployed to Heroku. Static files are deployed to S3 using S3Boto via Django's collectstatic command.
This depends a lot on the behaviour of S3 and the headers it sends when requesting files on S3. As you experienced, browsers will show different caching behaviour - so the best option is to use unique filenames.
I would suggest to use cachebuster hashes - in this way you can be sure that the new file always gets requested by browsers and you can use long cache-lifetime headers if you host the files on your own server.
You can for example create a MD5 hash of your minified file and append it (like mycss-322242fadcd23.css). Or you could use the revision number of your source control system. You have to use the cache buster in all links to this file, but you can normally easily do this in your templates where you embed your static resources. Depending on your application, you could probably use this Django plugin that should do this work for you.