Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Hi everyone, Bryan here. Peleus Uhley, Senior Security Researcher at Adobe, has written a guest post for the BlueHat blog on potential security issues with cross-domain access permissions for web sites. I d like to encourage you to read Peleus post and also to expand on it a little to talk about the SDL requirements around cross-domain access. Normally, the Same Origin Policy prevents web pages from interacting with resources hosted on domains other than the one they were loaded from. This is done for security reasons without the SOP it would be trivial for malicious sites to steal or alter data on other sites. However, there are so many great legitimate uses for cross-domain access like creating client-side mashups that several technologies have been developed to allow it under limited, opt-in circumstances. These technologies include Flash s crossdomain.xml policy file, also used by Silverlight Silverlight s clientaccesspolicy.xml policy file IE8 XDomainRequest object XMLHttpRequest Level 2 Access-Control headers JavaScript document.domain property redefinition Now, there s nothing inherently wrong with any of these although I have argued in the past that cross-domain XMLHttpRequest would destroy the internet . The problem with using these is that it s easy to inadvertently expose data to sites you don t intend to expose data to. Using wildcard domains when determining which domains have access permissions exacerbates this problem. The canonical example of this no pun intended is the crossdomain.xml setting This setting basically opens the web site up to cross-domain access from the entire internet. To help prevent sites from unintentionally exposing data to malicious external domains, the SDL requires any site with authenticated access to enumerate the specific domains it is allowing access to no wildcards allowed. Otherwise, the site is free to make its cross-domain access as permissive as desired. The original draft of the SDL cross-domain requirement was slightly different. Initially, the requirement included restrictions on the use of wildcards based on the depth of the wildcard i.e. two-dots vs. one-dot vs. no-dots and whether or not the site provided a private API . If a site contained only completely public resources, then it was allowed to use wildcards at the two-dots level or greater for example, .live.com would be allowed two dots but .com would not one dot . If a site had any resources only accessible by authenticated users, then no wildcards were allowed all domains with cross-domain privileges had to be explicitly enumerated in the appropriate policy file or header. However, we later realized that this requirement draft was both overly complicated and overly restrictive. If a site is completely public no authenticated access, no private or sensitive data then there s really no reason to restrict its access at all. The reason for this is that cross-domain attacks are luring attacks. To succeed, the attacker needs to lure a victim into performing some action on the attacker s behalf. For example, a cross-domain attack against a stock trading web site might cause the victim to send the attacker the complete details of his stock portfolio, or might cause the victim to make unintended trades. But in a completely public site, there s no personal data to steal and no possible authenticated actions to forge. There s no reason for an attacker to perform a luring attack they already have the same access to the same data that everyone else has. When we realized that our requirement was too restrictive, we changed it to its current form. However, let s re-examine the requirement in light of Peleus research on cross-domain access chaining. To give an extremely brief summary for those who haven t read it yet cross-domain permissions are transitive. If site A grants privileges to site B, and site B grants privileges to site C, then site A is implicitly and perhaps unknowingly granting privileges to site C. For the completely public site the potential of privilege chaining is a non-issue in terms of SDL requirements we ve already said it s acceptable to grant global access if desired. However, the situation is more complicated for the site with authenticated actions. It is true that even with wildcard domains being prohibited, there is still the possibility that one of an authenticated site s allowed domains could chain access to a potentially malicious third site. Unfortunately, short of banning cross-domain access entirely, there is no way to completely prevent this possibility. In most situations it would be impossible to map out a list of 3rd and 4th and nth order chained domains at development time, and furthermore it would be pointless since the list could change at any time even after the app has been deployed. In light of this research, we will be evaluating ways in which we can adapt the cross-domain requirement to continue to prevent unintended access from third-party domains. However, the requirement as it stands now remains useful and relevant. It raises the bar for attackers while imposing minimal design constraints and minimal time investments on the part of the development team. Please let us know if you have any feedback on this requirement. Do you feel it s too restrictive Or maybe it s not restrictive enough Feel free to write us or leave a comment here.

Les mots clés de la revue de presse pour cet article : security
Les videos sur SecuObs pour les mots clés : security
Les mots clés pour les articles publiés sur SecuObs : security
Les éléments de la revue Twitter pour les mots clé : security





Les derniers articles du site "The Security Development Lifecycle" :

- Visual C 2010 and Improved SAL Support
- New BSIMM report released...
- Do what Microsoft did, not what they do.
- Community and Collaboration
- Now available Microsoft SDL version 5
- Survey Results Microsoft SDL awareness on the rise
- Using Fortify Solutions for a Microsoft SDL Implementation
- Telling their SDL stories IE8 and Office 2007
- Announcing Elevation of Privilege The Threat Modeling Game
- SDL and the New End to End Trust Site

---

S'abonner au fil RSS global de la revue de presse

---