We've came across a strange user-agent string in our server logs. A browser (pretending to be an iOS Safari 9.0) had WalletPasses/1.2.3 at the end of the user-agent HTTP header.
What's that device or software?
A quick Google search reveals https://walletpasses.io. From there:
Wallet Passes allows you to use your Apple® Wallet / Passbook® Passes on Android™
So I'm guessing that they're spoofing the iOS Safari user-agent to make websites offer Apple Wallet to them.
Related
When hosting a website using HTTP Authentication, if the client has not authenticated, the server will send a 401 Unauthorized response, including a WWW-Authenticate header. An optional directive in this header is realm:
A string describing a protected area. A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning), and informs users about which paricular username/password are required.
(emphasis mine)
Let's say www.example.com requires authorization and has configured a realm value of Test Area. Back in the day, most web browsers would display a login dialog when receiving such a response, and say something along the lines of "Authorization required. The site at www.example.com says 'Test Area'."
But (at least recent versions of) Chrome, Firefox, and Edge, now all just display a generic message, without including the realm value. Interestingly enough, IE still displays the realm value (screenshots below, all Windows 10 64bit):
Chrome (v93.0.4577.82)
Firefox (v92.0)
Edge (v93.0.961.52)
IE (v11.1411.18362.0)
I'm pretty sure Firefox and Edge used to display it. Chrome may have a while back but seems like it was the first to stop. Since all modern browsers aren't displaying it, I assume there's some reason why..?? I've search all over the internet, and can't figure it out. I have a use-case where it would be helpful to users to have the realm displayed, as it would make it clearer which particular credentials they need to use. I know that you can't force the browser to display it, but it's just annoying. However if there is a valid reason for it not being shown I'll accept that.
The reason is that this could be abused for phishing attacks, by putting some misleading message into the realm. The login dialog for http authentication is part of the trusted browser UI, and giving the server the opportunity to modify that UI - even by just displaying text - is a security risk.
I'm making a PWA and is hosted on Firebase. I can see my page in Chrome, IE and other browsers. But I have problems with Safari and Opera. I have SLL certificade and TLS 1.2 (both from firebase) with nginx as server.
I tested my page on browsers and I get errors like:
"Safari can't open the page -url- besause safari can't establish a
secure connection to the server -url-"
"Can't establish
communication with protocol SSL/ TLS"
"Fatal Error (70) from
server " (Opera/Debian)
And in htbridge I got:
*HTTPS protocol, failed CSP status
*Many "The header was not sent by the server."
*I don't have have a Certification Authority Authorization (CAA) record.
*No support of TLSv1.3
*Server doesn't provide HPKP
So, I guess is something about security. But I don't know why it can be the main problem.
I tried to correct some stuff some commands on the server (nginx) but I don't know where is that or what I need to do. I am new to these things and I need someone to guide me a little at this point.
What should I do or is something I don't know?
Opera is exactly following the footsteps of Chrome, so if it works on Chrome shouldn't be problem on Opera, i would say just uninstall the Opera and re-install it. Also, check what versions you have got? to get he maximum of both browsers you need latest versions. Also, there are certain restrictions on Safari regarding PWA and service worker. Although, both Safari and MS Edge working on it and all the main browsers are getting into the same page on the issue of PWA (i.e. Service worker, Cache Api and IndexedDB).
It turns out that I was testing on obsolete versions of Safari and Opera for Windows. For some reason it did'nt work on a specific iphone and hence my confusion. Thank you for your help!
On Safari in iOS 10 my video doesn't work, only showing the play-icon.
I serve the video via an asp.net server, which checks to make sure the user has logged on and have access to the video. Only, on iOS 10 the server will respond with 401 Unauthorized!
Doing some testing with the code below, I found that safari on iOS 9 sends the ".ASPXAUTH" cookie - but safari on iOS 10 doesn't!
<video crossorigin="use-credentials" controls autoplay="autoplay">
<source src="/Server/GetVideo.ashx?id=123"/>
</video>
Why is safari not able to play my video? Is there any way to solve it?
My solution is here:
https://stackoverflow.com/a/40015409/7012293
Basically you need to send a 403 forbidden if the session cookie is missing. Safari will retry with the session cookie.
We have the exact same problem with a completely different technology stack (Linux, PHP, Moodle). Our session cookie is not sent with video (and audio) requests.
We weren't able to figure out a way to make iOS behave properly here, so we are doing an emergency patch to solve the problem by detecting iOS 10 and sending it to a different script to serve the video, passing a securely encrypted version of the session cookie value inside the path to this script, and then doing various hacks so that the value from the path gets used to identify the session from within that script (instead of the nonexistent cookie). This change works but is complex, has minor security implications, and might be harder to implement on different technologies.
This seems like a major problem with iOS 10 so I would hope that it might be fixed in a future update. Also, I note that although our session cookie is not included with the video, several other cookies are included! I couldn't actually figure out which ones weren't. (One of the first things I tried was to use a timed-expiry instead of session cookie, but this didn't get sent with the video either.)
Solution is to be found here:
HTML5 video/audio player on mobile Safari (iOS 7 & iOS 10) excludes cookies
Set an expire date to the cookie and the video player in iOS 10 can read back the cookie. Session cookies without an expire date can not be read back by the video player in iOS 10.
I'm exploring the idea of HTTP Origin checks as CSRF protection for Drupal at https://www.drupal.org/node/1803712
Now I was testing how the Origin header arrives with a POST request, but Firefox does not send the Origin header on the user login form submission. Chromium and Chrome work fine, they send the Origin header.
Firefox version is 36.0.1. I also tested with a clean Firefox installation because I thought maybe some of my browser plugins suppress the Origin header, but no luck - no Origin header there either.
Is there a documentation page that describes when Firefox sends the Origin header and when not?
Is isn't implemented yet. There's a discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=446344
The default on Firefox is not to send HTTP_ORIGIN.
The reason is a bug that causes hangs on some mobile Firefox versions if the network.http.sendOriginHeader configuration variable (accessible via about:config) is enabled. (For details see https://developer.mozilla.org/en-US/Firefox/Experimental_features#Security and the link provided by Marco's comment https://bugzilla.mozilla.org/show_bug.cgi?id=446344.)
There is a proposal to enable FF sending HTTP_ORIGIN by default, but the TODO list is long (see https://bugzilla.mozilla.org/show_bug.cgi?id=1424076).
So it will probably take years until FF will generally send HTTP_ORIGIN even without Javascript code enabling CSRF.
Some FOSS OSes preconfigure their FF ports to send HTTP_ORIGIN by default.
BTW, MS Edge also does not send HTTP_ORIGIN without explicitly enabling CSRF using Javascript.
For this reason I have implemented a security setting of my site which enables the users to disallow POST transactions from browsers that do not provide HTTP_ORIGIN.
I have an web application in which I generate a download link to an external google resource. This request usually needs a cookie. Because of the cross domain policy I currently download the files with curl and then pass them through to the user. Now those files are large. So I was looking for a way to download them directly through the clients browser.
Playing around I've found out that I can append the cookie in question to the http query, but this only works if no other cookies are set! Since it's google almost all users will have set some cookies for .google.com. Is there any way (maybe some security feature or bug) I can trigger a download request for that file in the users browser without sending any cookies along.
I discovered that I can make a request to *.google.com. (notice the . at the end) and then most browsers won't send any cookies set for .google.com . I've did a quick test using browsershots and on my own devices. The hack works in almost all browsers except for Safari (desktop and mobile) and some no name browsers.
While this works, I've decided not to use that method because the file name will be set to something unusable (no file extension).