Closed leastprivilege closed 7 years ago
As for CSP, we only render a couple of HTML pages (same list that's of concern for XFO). These are: authorization response when response_mode is form_post, check session page, and end session callback page.
So what XSS threats do we have on those pages:
Authorize response
The dynamic values rendered here are hidden inputs on the form. All the request values rendered, except for state are validated against our config. error and _errordescription are also values rendered to this page. When we render any values to the html page, ToFormPost
does html encode these values. And this is only rendered after the completed authorization request pipeline.
Check session The only thing that's dynamically emitted on this page is the name of a cookie, which comes from our server side config. As of today all the JS is embedded in the HTML page for convenience (one less round trip and less thing we have to serve up from IdentityServer).
End session callback The only thing that's dynamically emitted on this page are the client logout URLs from our config (which include the sid and issuer). We only render this page when properly authenticated with a sid param.
So in summary, for the few pages we render I don't see a huge attack vector for malicious inputs. We could add the CSP headers to be overly cautious, though.
All done. CSP on those 3, and XFO on end session callback
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Maybe want XFO on end session callback, but we'd need to white list the domain of the logout page to only allow our own logout page.
i can't see any other endpoints we have that needs XFO. we should strongly encourage people to do this in their UI code tho, and perhaps we should add this to our host/QS UI (and use https://github.com/NWebsec/NWebsec).