Confirm
716
edits
Changes
→Security worries
* Should we check for PIs even if HTTP headers has said that access is granted? It'll always be possible to circumvent those headers using .mimetypeOverride which'll make us not treat the doc as XML and thus we won't even look for PIs. Alternatively we could ignore the .mimetypeOverride when checking for PIs but that might be a problem with poorly configured servers (which is the whole reason for .mimetypeOverride)
** Do not pay attention to .mimetypeOverride when checking for PIs(It's ok to require that servers are properly configured. May not work for everyone, but it's safer)
** If headers grant access do check for PIs
** If headers denies access don't check for PIs
** Not including the authentication header makes it harder on CGIs since the webserver might deny access before the CGI even gets a chance to react.
* Do NOT send custom headers or cookies when talking to external sites -- this risks exposing sensitive IDs, usernames, and passwords when talking to third party services.** We'll only include the cookie headers for the external site. Not the headers of the requesting site. It should be ok to include the cookie headers for the external site since such requests can be created already.** Might be a good idea to disallow custom headers when talking to external sites since such headers could confuse the server in unpredictable ways.
* I don't see an adequate threat model described here -- what are the kinds of activities that a potential attacker might use this channel to do, and what are some ways to prevent this? For example, how will cross site XHR be used in conjunction with cross site scripting attacks?
** Good point. We should create a real threat model.
