Changeset 100877 in webkit
- Timestamp:
- Nov 20, 2011 6:26:16 PM (12 years ago)
- Location:
- trunk
- Files:
-
- 1 deleted
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/LayoutTests/ChangeLog
r100866 r100877 1 2011-11-20 Adam Barth <abarth@webkit.org> 2 3 REGRESSION(r100691): Safari error pages and Growl notifications fail to load stylesheets 4 https://bugs.webkit.org/show_bug.cgi?id=72836 5 6 Reviewed by Sam Weinig. 7 8 Update test results to show that XMLHttpRequets for directory listings 9 aren't blocked. 10 11 * fast/xmlhttprequest/resources/xmlhttprequest-nonexistent-file-real.html: 12 * fast/xmlhttprequest/xmlhttprequest-nonexistent-file-expected.txt: 13 1 14 2011-11-19 James Robinson <jamesr@chromium.org> 2 15 -
trunk/LayoutTests/fast/xmlhttprequest/resources/xmlhttprequest-nonexistent-file-real.html
r51294 r100877 21 21 { 22 22 log("ReadyState handler: readyState = " + xhr.readyState); 23 23 24 if (xhr.readyState == 4 && window.layoutTestController) { 25 var results = window.top.document.getElementById('results'); 26 results.innerHTML = document.body.innerHTML; 27 24 28 setTimeout("layoutTestController.notifyDone()", 0); 25 29 } -
trunk/LayoutTests/fast/xmlhttprequest/xmlhttprequest-nonexistent-file-expected.txt
r62629 r100877 1 CONSOLE MESSAGE: line 1: XMLHttpRequest cannot load . Cross origin requests are only supported for HTTP.2 1 3 2 Bug 22475: REGRESSION: Async XMLHttpRequest never finishes on nonexistent files anymore … … 13 12 ReadyState handler: readyState = 1 14 13 ReadyState handler: readyState = 4 15 Error handler: readyState = 416 14 -
trunk/Source/WebCore/ChangeLog
r100874 r100877 1 2011-11-20 Adam Barth <abarth@webkit.org> 2 3 REGRESSION(r100691): Safari error pages and Growl notifications fail to load stylesheets 4 https://bugs.webkit.org/show_bug.cgi?id=72836 5 6 Reviewed by Sam Weinig. 7 8 This patch removes a (minor) security mitigation. Previously, we tried 9 sequester "directory listings" into unique origins to make it more 10 difficult for an attacker to crawl the user's local file system. 11 Unfortunately, this mitigation doesn't really buy us much security 12 because if the attacker has access to local files, we've probably lost 13 anyway. 14 15 The larger problem, however, is that this condition is overly 16 complicated and has broken in sublte ways several times in its 17 (relatively short) lifetime. In the cases reported in this bug, we see 18 that this check affects error pages in Safari and Growl notifications, 19 even those have nothing to do with directory listings. 20 21 If we have our heart set on this directory listing mitigation, we'll 22 need a more robust way of triggering the behavior than examining URLs 23 and guess whether they contain directory listings. For example, if we 24 implement Allow-From or Access-Control-Deny-Origin, then the embedder 25 can supply those policies along with the directory listings. Those 26 seem like much better solutions than the in-engine hack this patch 27 removes. 28 29 * page/SecurityOrigin.cpp: 30 (WebCore::shouldTreatAsUniqueOrigin): 31 1 32 2011-10-17 Antonio Gomes <agomes@rim.com> 2 33 -
trunk/Source/WebCore/page/SecurityOrigin.cpp
r100716 r100877 87 87 } 88 88 89 static bool isDirectory(const String& path)90 {91 return path.endsWith("/");92 }93 94 89 static bool shouldTreatAsUniqueOrigin(const KURL& url) 95 90 { … … 114 109 if (SchemeRegistry::shouldTreatURLSchemeAsNoAccess(protocol)) 115 110 return true; 116 117 // We use unique origins for directory listings to make it harder to crawl118 // a local filesystem. Notice that we apply this protection only when we119 // use the outer URL for the security context because schemes that wrap120 // other URLs don't have directory listings.121 if (SchemeRegistry::shouldTreatURLSchemeAsLocal(protocol) && !shouldUseInnerURL(url)) {122 if (!innerURL.hasPath() || isDirectory(innerURL.path()))123 return true;124 }125 111 126 112 // This is the common case.
Note: See TracChangeset
for help on using the changeset viewer.