Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
On 11/1/16 6:36 AM, Roger Hågensen wrote: Wait, are you saying that ContentSecurityPolicy can't be relied upon? It depends on your threat model. Content security policy is a tool that allows a web page to defend itself and its users from cross-site script injection attacks and the like. A fundamental assumption here is that the user is NOT the attacker, and hence the user's browser is cooperating with the web page to protect the user. It's a perfectly fine tool for the "user and page author are cooperating" threat model. If, on the other hand, your threat model includes attacks by the _user_ on your server, you absolutely can't rely on CSP to defend against that. Most simply, the user can use a browser that doesn't support CSP. For addressing this class of attacks, you _have_ to rely on a completely server-side solution, because by assumption the client (the browser) is the attacker in this situation. -Boris
Re: [whatwg] possible new parameters to video.play() ?
On 09/19/2016 07:41 AM, Simon Pieters wrote: There is always room for adding convenience APIs, it's a matter of demonstrating that it's a common enough need to make it worth the cost of adding it. https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94 HTH, * OFF TOPIC * Going off topic but an excellent example of what can happen when those things in the link aren't considered are the ramifications of adopting of Google's HPKP (RFC 7469) * Even though TLS is used over a wide range of protocols, it is specific to one protocol - HTTP. The Internet is bigger than the web, a proper solution to a problem that exists across protocols isn't limited to just one protocol. * It is blind trust on first use, which means the pins have to be cached for a relatively long time (to reduce window when that blind trust can be exploited) * Thus you have to have at least one spare private key before deploying, so that its keypin can be cached by browsers as well. * That spare private key can't be kept as the same place as the main key because if the main key is stolen via file access, the spare key will likely be compromised too. * In addition to needing to keep the spare key in a separate place that is secure, it ties you in to specific technology because of the long cache life. Thus if your private key is compromised because of a zero day that only works on RSA keys you can't switch to ECDSA unless your spare key is already ECDSA. * Puts you at the mercy of the browser vendors. What happens if you were using secp521r1 when Chrome decided to drop it? I hope people had backup keys that weren't secp521r1/ * If an employee leaves a company that potentially had access to private keys, it means you can't immediately rotate all the private keys to shiny new ones. All those problems exist because it was implemented (initially in Chrome) without careful consideration. Rich companies like Google can do that. And it has hampered the adoption of a better technology (DANE) that doesn't have any of those issues. So yes, adding new features really does require very careful thought. * BACK ON TOPIC * That being said, I like the attribute idea for audio and suspect it may have less accessibility issues than using JavaScript might have, notably it being easier for software to notify the user what the start and stop times are by reading them directly from the audio tag attributes. So I like the idea.
Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
On 11/01/2016 03:32 AM, Roger Hågensen wrote:
On 2016-11-01 10:42, Roger Hågensen wrote:
I was wondering how can a server or script identify if a request is from
page, iframe or xhr?
I really hate answering myself (and so soon after making a post) but it
seems I have found the answer at
https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives
and the support is pretty good according to
http://caniuse.com/#feat=contentsecuritypolicy
But on MDN it says "For workers, non-compliant requests are treated as
fatal network errors by the user agent."
But does this apply to non-workers too?
And is there any way to prevent injected hostile scripts?
I guess loading scripts from a specific (whitelisted) url could do the
trick? Or maybe using strict-dynamic.
Darnit it. I may just have answered my own questions here.
Somewhere in the document (body, main, etc.) when a page is generated I
include a data-csrf attribute that contains a single use token only good
for the session id that requested the page (session id in the cookie)
Then any post submission, JS reads that token and adds it to the POST data.
In the case of Ajax submissions, the Ajax response includes a fresh
token that then gets inserted into the data-csrf attribute for the next
time the page sends a POST response.
My web apps usually put it in whatever element has the id of content so
reading it via jQuery is as easy as
$("#content").attr("data-csrf");
Then with the json response, updating it to new token is as easy as
$("#content").attr("data-csrf", json.csrf);
It allows single use tokens and makes CSRF attacks virtually impossible
as long as you have a proper crypto random string generator to create
the new CSRF tokens so they can't be predicted.
Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
On 2016-11-01 11:26, Michael A. Peters wrote: Any server admin that trusts a header sent by a client for security purposes is a fool. They lie, and any browser extension or plugin can influence what headers are sent and what they contain. Wait, are you saying that ContentSecurityPolicy can't be relied upon? (regarding me finding CSP see my answer to myself in another message) -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
On 2016-11-01 10:42, Roger Hågensen wrote: I was wondering how can a server or script identify if a request is from page, iframe or xhr? I really hate answering myself (and so soon after making a post) but it seems I have found the answer at https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives and the support is pretty good according to http://caniuse.com/#feat=contentsecuritypolicy But on MDN it says "For workers, non-compliant requests are treated as fatal network errors by the user agent." But does this apply to non-workers too? And is there any way to prevent injected hostile scripts? I guess loading scripts from a specific (whitelisted) url could do the trick? Or maybe using strict-dynamic. Darnit it. I may just have answered my own questions here. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
Re: [whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
On 11/01/2016 02:42 AM, Roger Hågensen wrote: I was wondering how can a server or script identify if a request is from page, iframe or xhr? Doing this would not prevent any XSS attacks, but it would allow a server/server-side script to detect a potential XSS attack. I could not find any mention of any reliable way to do this currently. Here is an example of this idea, when the browser fetches the page the server sends this as a response header to the browser... RRS: * or RRS: url or RRS: iframe or RRS: script And when the browser do a POST it will send one of these (if the server sent a RRS header) ... Any server admin that trusts a header sent by a client for security purposes is a fool. They lie, and any browser extension or plugin can influence what headers are sent and what they contain. The only thing you really can do with POST is set a single use CSRF token that the browser must include with the POST data. If the browser does not send the token or sends an incorrect/expired token for the session ID then the server rejects the post (I send a 403 forbidden)
[whatwg] How can a server or serverside script identify if a request is from a page, iframe or xhr?
I was wondering how can a server or script identify if a request is from page, iframe or xhr? Doing this would not prevent any XSS attacks, but it would allow a server/server-side script to detect a potential XSS attack. I could not find any mention of any reliable way to do this currently. Here is an example of this idea, when the browser fetches the page the server sends this as a response header to the browser... RRS: * or RRS: url or RRS: iframe or RRS: script And when the browser do a POST it will send one of these (if the server sent a RRS header) ... RRS: url or RRS: iframe or RRS: script RRS is short for "Report Request Source/Reported Request Source". "url" indicate that the request source was a form on the page of the requested url. "iframe" indicate that the request source was from within a iframe on the page of the requested url. "script" indicate that the request source was from a script (via xhr) on the page of the requested url. If a server (or server script) is only expecting a POST from the page but get a RRS result of iframe or script then this could be logged and reported to the server security supervisor for review. The server sending "RSS: *" indicate that the request should be allowed but reported (might be nice for debugging as well). If it is "RSS: url" then any requests from a iframe or a script would be denied/blocked by the browser (blocking two methods of making a POST) Now if there exist another way to achieve the same and I just haven't found it I'd appreciate if someone pointed me in the right direction. I'm also a bit unsure what working group (pun intended) a suggestion should be directed to if this does not exist yet. -- Roger Hågensen, Freelancer, http://skuldwyrm.no/
