yunfour / myblogs Goto Github PK

#location.replace() 的使用场景

location.replace(url)的方法相比大家都比较熟悉，其作用和location.href = 'url';的目的累死，也是使用js跳转页面；当然和location.href的区别在于location.replace方法会替换掉当前页在历史记录栈中的节点，而location.href会在历史记录栈中压入一个新节点。

放到一个比较场景的场景中，在A页面中，有一个链接，点击后调整登录页面B，在登录页B登录成功后，会调整到另外一个新页面C，如果在登录页面登录成功后，使用location.href = 'C页面的url'方式跳转，进入C页面后，点击浏览器返回按钮，则会返回到登录页面B，按逻辑将是合理的，但是按交互场景来说是不合理，因此此时用户已经登录，返回到登录页面还会出现填写登录信息的界面。

根据以上场景，在登录页面登录成功后，使用location.replace('C页面的url')的方式跳转到C页面后，点击浏览器返回按钮，就会返回的A页面，因为location.replace方法吧登录页B在历史记录栈中的节点替换掉了。

本人之前在开发微信APP时，开始也是使用location.href的方式跳转，交付测试后被QA同学提出，用户明明已经登录成功了，点击微信的返回按钮，怎么又回到登录页面了；此时就是使用location.replace方法的时候了。

XSS攻击，在WEB安全领域已经是老生常谈的问题，每每提到安全问题，也会首当其冲拿出来说事。

针对XSS攻击的解决方案，也非常成熟，主要就是：对用户输入信息的地方进行转义处理，当然我这里要提起的一个点，并非这个方案的问题，而是在开发时，（我）经常忽略的一个点。说之前先提一下之前的一次经历：

我的岗位是前端开发，当时在开发网站的时候，页面中有一个分页效果，对应页码数据通过web的URL的参数传递过来，为了方便（偷懒），直接在URL中提取了该页码的数据，比如页面URL为：www.x.com/xxx?page=1 ，在js中直接直接获取url的页码page=1，而此处的分页组件正是由js生成的，xxx，在生成html后直接append到html文档中，此时又没有对page参数做任何转义处理，因此，此处就会造成一个XSS攻击的漏洞：

假使，此处的改页码的page参数经过篡改为：www.x.com/xxx?page= <script>alert('x');，page参数对应的数据完全注入的页面html文档中，其中的 alert('x') 脚本就会被网页执行。

当时，这个XSS安全问题是被测试同学，使用安全扫描工具给扫描出来的，我当时的反应是后端没有对用户的输入的内容做好转义，后来经过排查和后端完全没有关系，这个事情问题发生的很随意，我感觉很容易忽略，作为前端我本人经常通过js直接获取URL中的所需的数据，经历过此事之后，在使用URL中数据的时候，就多长了一个心眼，记得对其转移，或者直接使用后端返回的安全数据。

提到这个经历，主要做个总结、警告，安全无小事，不论前端、后端都会造成安全隐患，在开发过程中不能形成定性思维，出现问题直接定性为后端问题，前后端开发者都要认真审视自己的代码，防患于未然。