我最近找到了网站escape.alf.nu。它nerd sniped我非常努力，在解决或至少知道所有挑战的解决方案之前我无法离开它。一些答案真让我大吃一惊。但我仍然无法解决17,18和21，我无法在互联网上找到任何东西。
17和18引导我阅读了很多关于SOP绕道的内容。大多数旁路（通过帧名称，地址哈希，更新的postMessage（））都需要两侧的js代码。众所周知，您可以加载任何内容作为javascript或css，并可能从中获取一些信息，但它需要特定的输入格式（甚至javascript错误消息在现代浏览器中被阻止）。即使设置document.domain也不会起作用，即使域名是相似的，因为你无法在token17.alf.nu（或18）iframe上设置它。在我看来，真的公然违反了SOP，只能被浏览器漏洞（例如在Android默认浏览器中找到的漏洞）绕过。但是，如果有一个需要特定浏览器的话，那就违背了其他挑战的风格。在18岁时，他说＆＃34;我希望这一个在所有浏览器中都不会起作用，但听起来好像他预计它会在大多数情况下工作（很可能不是一个漏洞），更重要的是 - 如果这与之前显然适用于所有浏览器的级别相矛盾。
然后有21个人比其他更晚的关注更受关注，因为Alf从他对this question的回答中得到了更多的关注，作为他的简短回答是＆＃34;不够的＆＃34; 。人们给予该级别的答案是定义一个名为＆＃34; window＆＃34;或＆＃34; console＆＃34; - 在with语句之前，定义被提升到作用域的顶部，因此从不检查console.foo。但是这只能起作用，因为它在函数范围内运行。如果我们真的试图绕过控制台的阻塞（现在只有理论上已经不再有阻止它的已知方法）我们无法定义新的窗口或控制台，因为我们在全球范围内运行，我们可以＆ ＃39;重新定义这些名字。
21是基于Salman A对这个问题的回答。看起来它的意思是表明facebook实际使用的代码比Alf的例子更好，但真正重要的是这个级别用settimeout运行代码，确保它在全局范围内运行并且你无法覆盖窗口或控制台。我开始认为这个级别没有解决方案......任何人都找到了什么？