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.
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.
Bassically it is what the question says, It is like my website it is not save for the clients. (I do not have online payments or somethig like that)
The thing is that this only happen sometimes, and it is not always in the same device, for example it could happen in my pc once a week and the rest of the time works just fine.
I have beeing reading and it could be a lot of causes, but in this way that it is sometime I thing it is really weird, my ssl expires in four day, but this problem has been happen for about two months (the site has been 1 year online).
When I call to external links (for javascript or css) I checked and it is always https.
I also read that could be the browser or the OS but this has happened in chrome, mozilla and IE as browser and Windows 10, windows 8, ubuntu (last version at this time), android 5.0.1 as SO and my web server is linux.
I do not know what other information it is relevant, I try to give all I read could be relevant in this case.
To get more details you can :
Click on the slashed https
Open the console (The security tabs and the network tabs could help you too)
What could cause it:
Unsecure (http) requests
Unsecure ciphers ( check it with ssllabs.com )
Forms with http target
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).
I was trying to track down why my site was so painfully slow in IE9 when I pulled out Fiddler and realised that every request is being sent 3 times (twice I get 401.2 and then a success). I verified this happens on all browsers, its just that Chrome's speed was masking this (or it could be that this has nothing to do with my sites performance issues in IE).
I've set up break points in my begin/end request handlers and the request comes in for say a css file. It is not authenticated and the response goes out with a 401.2, I doubled checked that I'm not setting the response status anywhere myself, so somewhere between begin_request and end_request the status is changing to 401.2
Note: I have the runAllManagedModulesForAllRequests=true so I can configure compression, however this setting does not affect this (from what I can see from Fiddler).
I am very ignorant on kerberos/active directory in general but I just cannot fathom that this is a normal handshaking protocol for every single request (perhaps for the first? but not all).
I have scoured the googles and nothing seems to help (adding/removing modules/authentication providers, etc). I mean my site works just fine, its only once you look under the hood that I see the treplicated requests. Note: This also happens when I deploy to production so its not a server specific issue.
Has anyone ever seen this? thanks in advance.
I think this is how NTLM authentication works. The process is discussed here. Note that you will want to set AuthPersistSingleRequest to false to cut down on the number of 401s
I have a web app that is being hit by facebook. The login page retrieves the keys that I need and sets some session variables. When the server then redirects the user to the next page, the session information is lost. I’m running the IIS engine on vista ultimate at the moment, the app pools don’t matter because I’m using a state service and I’m still losing the session state. I’ve tried both the overloaded method of the response.redirect function and also adding a header to the page to force the redirect and none of this seems to work. Does anyone have any ideas of what I’m missing?
I’ve tried both of these:
Response.Headers.Add("refresh", "3;url=Dashboard.aspx")
And
Response.Redirect("Dashboard.aspx", False)
[EDIT]
So i just did a little experiment and well it turns out that when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
[EDIT]
So I found an article on this and after addin gthe header the problem was solved (for now)
http://support.microsoft.com/kb/323752
Response.AddHeader("P3P: CP", "CAO PSA OUR")
when I hit the url directly from the facebook page I get the problem, but when i copy the url for the IFrame into a new browser window and try it it works fine.
If you're in an iframe, any cookies you set are “third-party cookies”. Third-party cookies may be subject to more stringent conditions than the normal “first-party” cookies you are setting when the user is directly on your site. This can be due to different browser default cookie handling or because the user has deliberately configured it like that. (And for good reason: many third-parties are unpleasant privacy-invading advertisers.)
In particular, in IE6+ with the default settings, you cannot set a third-party cookie unless you write a P3P policy promising that you will be a good boy and not flog your users' data to the nearest identify thief.
(In practice of course P3P is a dead loss, since there's nothing stopping the site owner from just lying. Another worthless complication that provides no actual security. Yay.)
I'd try running Fiddler and see if your session cookie is being sent properly with the response when interacting with your app via Facebook.
The session depends also on cookie support by the client. When you say the app "is being hit by facebook" are you sure that by what ever means they are "hitting" you they are supporting cookies?
Response.Redirect and refresh don't carry session. Server.Transfer() can but loses the ability to transfer to other servers/sites.