WEB安全第八课 浏览器端脚本 之五 代码包含模式和嵌入风险

        经过前面的讨论，在当前页面的运行环境里执行脚本显然有多种方式。有必要再集中罗列一下几种最常见的方式：
        
        1.直接嵌人<script>代码块。
        2.通过<script src=...>加载远程代码。
        3.在各种HTML和CSS参数里通过javascript:URL触发调用。
👏🏠🍖🈷🐢‍        4.CSS expression(...)语法和某些浏览器里的XBL绑定。
        5.事件处理器（Event handlers)，譬如onload、onerror、onclick等。
        6.定时器Timers(setTimeout，setInterval)。
        7.eval(...)调用。

🤙🚤🍽☪🐂‎
        
        表面上看把这些方法组合起来使用也很正常，但这么做往往会造成极其难以预料和危险的解析链传递。例如，考虑一下在这段代码里，由服务器端提供的use_string值需要做哪些转换：
        
        [mw_shl_code=javascript,true]<div>[/mw_shl_code]
👌⛵🥣🚭🐠‌        
        通常很难注意到这个用户数据会经过至少三次解析！HTML解析器首先提取出onclick参数，把它放到DOM树里;之后当按钮被点击时，进人JavaScript引擎里做第一次解析，检查setTimeout(...)的语法;最后，在点击发生了1秒钟后，实际的do_stuff(...)函数才会被解析和执行。
        
        因此，在以上例子里，为确保整个过程的处理无误，user_string要先以JavaScript反斜杠编码方式进行处理，在此基础上要再加一层HTML实体编码，编码顺序也不能调乱。任何其他的处理方式都可能导致代码注人。
        
🤝🏫🫖🅿🐠‏        另一个充满陷阱的转义场景如下：
        
[mw_shl_code=javascript,true]        <script>
var some_value=nuser_string";
...🧑‍⚕️‏💎🪦😷👄
setTimeout("do_stuff('" + some_value 9+"')",1000);
</script>[/mw_shl_code]
        
        表面上看初始给some_value赋值时，user_string只需要做一次转义，但如果没有提前再做一次额外的转义，那么在之后的setTimeout(...)参数拼接里，仍然可能引人新的漏洞。
        
👍🚈🍧⁉🦉‌        这种有问题的编码模式在JavaScript编程里极其常见，而且极易被忽略。最好的办法是在开发时就提前避免这种问题，而不是事后再审核代码。