I'm referring to the "Internal UUID" value that's visible in about:debugging, which is different from the extension ID that is specified in manifest.json for web extensions.
In my testing, this is a different value for each installation of the addon.
I'd like to set this to a predictable value because it is used as the origin (e.g. moz-extension://guid) for communication APIs like postMessage. It'd be a good indicator for whether a message received by a web app is from an authorized extension vs. some other extension or page.
In Chrome, the origin seems to be stable across different installations of an extension, so I'd like to see if it's possible to achieve the same thing with Firefox.
The internal UUID is deliberately created per installation of an extension, to avoid fingerprinting, you can see a longer discussion at https://bugzil.la/1372288
However, I think you're misunderstanding the purpose of the Origin header, it lets your web app and browser work together to prevent a class of cross-site scripting attacks. But by itself, it doesn't really give your web app a reliable indicator of the origin of the request (that is, any non-browser client can easily construct an HTTP request with an arbitrary value in the Origin header)
Related
I just got to know about the same origin policy in WebAPI. Enabling CORS helps to call a web service which is present in different domain.
My understanding is NOT enabling CORS will only ensure that the webservice cannot be called from browser. But if I cannot call it from browser I still can call it using different ways e.g. fiddler.
So I was wondering what's the use of this functionality. Can you please throw some light? Apologies if its a trivial or a stupid question.
Thanks and Regards,
Abhijit
It's not at all a stupid question, it's a very important aspect when you're dealing with web services with different origin.
To get an idea of what CORS (Cross-Origin Resource Sharing) is, we have to start with the so called Same-Origin Policy which is a security concept for the web. Sounds sophisticated, but only makes sure a web browser permits scripts, contained in a web page to access data on another web page, but only if both web pages have the same origin. In other words, requests for data must come from the same scheme, hostname, and port. If http://player.example tries to request data from http://content.example, the request will usually fail.
After taking a second look it becomes clear that this prevents the unauthorized leakage of data to a third-party server. Without this policy, a script could read, use and forward data hosted on any web page. Such cross-domain activity might be used to exploit cookies and authentication data. Therefore, this security mechanism is definitely needed.
If you want to store content on a different origin than the one the player requests, there is a solution – CORS. In the context of XMLHttpRequests, it defines a set of headers that allow the browser and server to communicate which requests are permitted/prohibited. It is a recommended standard of the W3C. In practice, for a CORS request, the server only needs to add the following header to its response:
Access-Control-Allow-Origin: *
For more information on settings (e.g. GET/POST, custom headers, authentication, etc.) and examples, refer to http://enable-cors.org.
For a detail read, use this https://developer.mozilla.org/en/docs/Web/HTTP/Access_control_CORS
I recently got my hands on an relatively old cordova app for iOS (iphones), which was built around one year ago, in order to debug it.
The app queries an API from a server. This server is built using Laravel and makes use of laravel-cors.
For a peculiar reason, the developers of this app have set up CORS server-side to accept requests, only if the Origin header is missing.
I was told that the app was working just fine for the past year.
While debugging it, I noticed that the iOS browser adds origin => 'file://' to its headers, when cordova app uses $.ajax for doing requests
And now for my questions
Are you aware of such a change on newer iOS verions?
I suppose I can't do anything client-side in order to bypass it?
How safe is to add "file://" as an accepted origin, server-side?
Thanks a ton!
The reason the server accepts null-Origin isn't "peculiar" -- that is how CORS is defined to work. It is intended to protect against browser-based XSS attacks -- browsers send the Origin header automatically so the server can accept or reject the request based on which domain(s) they allow javascript calls from. It is intended as a safe standards-based successor to the JSONP hack to allow cross-origin server requests, but in a controlled way. By default, browsers require and allow only same-origin XHRs and other similar requests (full list).
CORs is undefined for non-browser clients, since non-browser clients can set whatever Origin they want to anyway (e.g. curl), so in those cases it makes sense to just leave off the Origin header completely.
To answer part of your question, it is not (very) safe to add file:// as an accepted origin server-side. The reason is that an attacker wishing to bypass CORS protections could trick a user into downloading a web page to their filesystem and then executing it in their browser -- thus bypassing any intended Origin restrictions since file:// is in the allowed list. There may also be other exploits, known and unknown, that could take advantage of servers that accept a file:// origin.
You'll have to evaluate the risks of adding this based on your own project requirements.
I'm developing a Google Sheets add-on. The add-on calls an API. In the API configuration, a url like https://longString-script.googleusercontent.com had to be added to the list of urls allowed to make requests from another domain.
Today, I noticed that this url changed to https://sameLongString-0lu-script.googleusercontent.com.
The url changed about 3 months after development start.
I'm wondering what makes the url to change because it also means a change in configuration in our back-end every time.
EDIT: Thanks for both your responses so far. Helped me understand better how this works but I still don't know if/when/how/why the url is going to change.
Quick update, the changing part of the url was "-1lu" for another user today (but not for me when I was testing). It's quite annoying since we can't use wildcards in the google dev console redirect uri field. Am I supposed to paste a lot of "-xlu" uris with x from 1 to like 10 so I don't have to touch this for a while?
For people coming across this now, we've also just encountered this issue while developing a Google Add-on. We've needed to add multiple origin urls to our oauth client for sign-in, following the longString-#lu-script.googleusercontent.com pattern mentioned by OP.
This is annoying as each url has to be entered separately in the authorized urls field (subdomain or wildcard matching isn't allowed). Also this is pretty fragile since it breaks if Google changes the urls they're hosting our add-on from. Furthermore I wasn't able to find any documentation from Google confirming that these are the script origins.
URLs are managed by the host in various ways. At the most basic level, when you build a web server you decide what to call it and what to call any pages on it. Google and other large content providers with farms of servers and redundant data centers and everything are going to manage it a bit differently, but for your purposes, it will be effectively the same in that ... you need to ask them since they are the hosting provider of your cloud content.
Something that MIGHT be related is that Google rolled out some changes recently dealing with the googleusercontent.com domain and picassa images (or at least was scheduled to do so.) So the google support forums will be the way to go with this question for the freshest answers since the cause of a URL change is usually going to be specific to that moment in time and not something that you necessarily need to worry about changing repeatedly. But again, they are going to need to confirm that it was something related to the recent planned changes... or not. :-)
When you find something out you can update this question in case it is of use to others. Especially, if they tell you that it wasn't a one time thing dealing with a change on their end.
This is more likely related to Changing origin in Same-origin Policy. As discussed:
A page may change its own origin with some limitations. A script can set the value of document.domain to its current domain or a superdomain of its current domain. If it sets it to a superdomain of its current domain, the shorter domain is used for subsequent origin checks.
For example, assume a script in the document at http://store.company.com/dir/other.html executes the following statement:
document.domain = "company.com";
After that statement executes, the page can pass the origin check with http://company.com/dir/page.html
So, as noted:
When using document.domain to allow a subdomain to access its parent securely, you need to set document.domain to the same value in both the parent domain and the subdomain. This is necessary even if doing so is simply setting the parent domain back to its original value. Failure to do this may result in permission errors.
I'm communicating with an API that requires I use a particular user-agent string. The format for this is basically User-Agent: IOS_USER_AGENT API_CUSTOM_AGENT
Upon investigation I discovered that people would use UIWebView and apply a javascript function to extract the system user agent string. Now that UIWebView is deprecated, its replacement WKWebView offers an asynchronous means of calculating the user agent (not ideal for my purposes).
Is there any way to extract some form of the iOS user agent string without needing to randomly create some off-screen web view. Especially with SFSafariViewController I don't think its entirely impossible that these web views become deprecated in future.
I know that Apps like WhatsApp and Facebook use the system User-Agent see here. The question is, what is the most reliable way of achieving this without involving web view trickery?
Seeing some odd behaviour in Chrome, and not sure if it's expected behaviour when using appcache, or just Chrome.
It's a single-page app, powered by our RestAPI, it works fine when the RestAPI is being requested under HTTP, however as soon as we change the url to be the HTTPS version then it stops working. There's not a lot (i.e. any) information in Chrome's console as to why it decides to stop working.
We've managed to narrow it down to the NETWORK section in the appcache file, the only way we can get it to work is to use the * wildcard, which we don't want to do, as that bypasses the whole point of the appcache, and reduces security (from my understanding from reading the docs etc).
We've tried any and all variations of the API url (as in combinations of it with wildcards in various relevant locations), but none seem to work (even a https://* doesn't allow a successful request).
Any experienced know what's going on at all?
Thanks
Need a bit of clarification (see my comment), but in the meantime:
The NETWORK behaviour of the manifest is really there to, according to the spec, make "the testing of offline applications simpler", by reducing the difference between online and offline behaviour. In reality, it just adds another gotcha.
By default, anything that isn't explicitly in the manifest (listed in the manifest file), implicitly part of the cache (a visited page that points to the manifest), or covered by a FALLBACK prefix, will fail to load, even if you're online, unless the url is listed in the NETWORK section or the NETWORK section lists *.
Wildcards don't have special meaning in the NETWORK section, if you list http://whatever.com/* it will allow requests to that url, as an asterisk is a valid character in a url. The only special case is a single *, which means "allow the page to make network requests for any resources that aren't in the cache".
Basically, using * in NETWORK isn't a security risk, in fact it's probably what you want to do, every AppCache site I've built uses it.
I drew this flow chart to try and explain how appcache loads pages and resources: