One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8328958 |
| Date de publication | 2023-04-18 12:00:25 (vue: 2023-04-18 17:06:32) |
| Titre | Hébergeant en toute sécurité les données des utilisateurs dans les applications Web modernes Securely Hosting User Data in Modern Web Applications |
| Texte | Posted by David Dworken, Information Security Engineer, Google Security Team Many web applications need to display user-controlled content. This can be as simple as serving user-uploaded images (e.g. profile photos), or as complex as rendering user-controlled HTML (e.g. a web development tutorial). This has always been difficult to do securely, so we\'ve worked to find easy, but secure solutions that can be applied to most types of web applications. Classical Solutions for Isolating Untrusted Content The classic solution for securely serving user-controlled content is to use what are known as “sandbox domains”. The basic idea is that if your application\'s main domain is example.com, you could serve all untrusted content on exampleusercontent.com. Since these two domains are cross-site, any malicious content on exampleusercontent.com can\'t impact example.com. This approach can be used to safely serve all kinds of untrusted content including images, downloads, and HTML. While it may not seem like it is necessary to use this for images or downloads, doing so helps avoid risks from content sniffing, especially in legacy browsers. Sandbox domains are widely used across the industry and have worked well for a long time. But, they have two major downsides: Applications often need to restrict content access to a single user, which requires implementing authentication and authorization. Since sandbox domains purposefully do not share cookies with the main application domain, this is very difficult to do securely. To support authentication, sites either have to rely on capability URLs, or they have to set separate authentication cookies for the sandbox domain. This second method is especially problematic in the modern web where many browsers restrict cross-site cookies by default. While user content is isolated from the main site, it isn\'t isolated from other user content. This creates the risk of malicious user content attacking other data on the sandbox domain (e.g. via reading same-origin data). It is also worth noting that sandbox domains help mitigate phishing risks since resources are clearly segmented onto an isolated domain. Modern Solutions for Serving User Content Over time the web has evolved, and there are now easier, more secure ways to serve untrusted content. There are many different approaches here, so we will outline two solutions that are currently in wide use at Google. Approach 1: Serving Inactive User Content If a site only needs to serve inactive user content (i.e. content that is not HTML/JS, for example images and downloads), this can now be safely done without an isolated sandbox domain. There are two key steps: Always set the Content-Type header to a well-known MIME type that is supported by all browsers and guaranteed not to contain active content (when in doubt, application/octet-stream is a safe choice). In addition, always set the below response headers to ensure that the browser fully isolates the response. |
| Notes | ★★ |
| Envoyé | Oui |
| Condensat | $random above access across active added adding addition additional advantage against all already also always ancestors any application application/octet applications applied apply approach approaches are attachment; attacking attacks authentication authorization avoid bar basic been being below blob block blocking browser browsers bugs but by: can cannot capability choice classic classical clearly com com/shim combination compared compatibility compatible complex compromise concept conclusion confidence contain contains content controlled cookie cookies core corp could create creates cross csp currently data david deal default defense degree depth developed development different difficult disables display disposition: documents doing domain domains domains” done doubt download downloaded downloads downsides: dworken each easier easily easy either embedded embedder embedding enable endpoint engineer ensure ensures especially event evolved example exampleusercontent execution file filename= find foo frame from fully furthermore generally google googleusercontent guaranteed handler hardening has have having header headers help helps here high hope hosting html html/js idea ie11 iframe images impact implement implementing improve inactive included including inclusion industry information injection inside isn isolate isolated isolates isolating isolation key kinds known layers lead legacy like likely list listens loaded long longer main major make malicious manner many matching may measures message method migrate migrated migrations mime mitigate model models modern modernizing more most multiple necessary need needs new next none nosniff not noting now number off often ongoing only onto opener option options: origin other outline outlined outside over overall page party phishing photos planned policy: popup possible posted postmessage prevents problematic process product products profile protection provide provides psl public purpose purposefully rather reading receives refinements rely rendered renderer rendering renders represents require requires resource resources response responses restrict restriction retrieving risk risks routed safe safely same sandbox sandboxed sandboxes second secure securely security security: seem segmented send separate separation serve served serving set setup share sharing shim short simple simplest since single site sites sniffing snippet solution solutions spectrejs src static steps: stream subdomain subresource subresources such sufficient suffix support supported svg take team tell than then these third threat through thus time to: together transformed triggers tutorial two type types unique untrusted uploaded urls use used user usercontent uses using value very vulnerabilities way ways weaknesses web websites well what when where which wide widely will without worked worth xss year your “sandbox |
| Tags | Threat |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.