2023年7月17日发(作者：)

Web安全——前端JS表单验证过滤前⾔之前忙于做各种事情，已经很久没写过⽂章，最近接的⼀个学校的⽹站项⽬，近期被⼈⽤⾃动脚本攻破了（笑...），因为我们第⼀次做这种上线的项⽬，完全没有意识到⼀些web安全的知识，所以就开始了紧急的漏洞补救和防护措施。所以我就把近期学习的知识总结下。⽬前我⽔平有限，只能做⼀个初级认识，让⼀些刚⼊⾏做上线的实际项⽬的同学能有所警惕。原因安全⼩⽩作为这个⽹站项⽬组长，我是完全不知道这些安全隐患问题的，团队的⼈员也没有研究过这些，所以造成了这个情况，因为我们是在校⼤学学⽣，确实学⽆余⼒来研究这些，希望对还未出社会的初学者提个醒。web常见攻击⼿段我只会⼤概提及它的攻击原理和预防⽅法，具体的实现和深⼊研究还请⼤家⾃⾏百度，因为只有真正需要⽤到才会去详细了解，这⾥我只为web安全⼩⽩做知识扫盲。因为博主⽬前接触最多的服务端语⾔是JAVA所以例⼦都从java web项⽬来讲。跨站脚本攻击（XSS）虽然我们⽬前做的是⼀个博客的⼩⽹站，但是以后⽆论是⾃⼰的博客还是实际的项⽬，都可以⽤图⽚来提供外链，⽅便管理，如果你的⽹站访问量很⾼啊，⼀天⼏⼗万⼏百万啊，我的天啊，这时候你考虑的就不是服务器空间够不够⼤，⽽是惊⼈的并发数啊，光是请求html⽂件（或其他）的链接就处理不过来了，哪还有多余的资源去读取图⽚啊，索性就把图⽚存另⼀个服务器吧，给主服务器减轻压⼒啊，于是图床诞⽣了。1. 反射型XSS它是通过诱使⽤户打开⼀个恶意链接，服务端将链接中参数的恶意代码渲染到页⾯中，再传递给⽤户由浏览器执⾏，从⽽达到攻击的⽬的。如下⾯的链接：/?name=xss将页⾯渲染成下⾯的html：Hello xss这时浏览器将会弹出提⽰框。这算是常见的⼀种⽅法，预防的话可以通过后台编写⽅法来拦截过滤到这些⾮法或有攻击性的字符。1. 持久型XSS持久型XSS将恶意代码提交给服务器，并且存储在服务器端，当⽤户访问相关内容时再渲染到页⾯中，以达到攻击的⽬的，它的危害更⼤。⽐如，攻击者写了⼀篇带恶意JS代码的博客，⽂章发表后，所有访问该博客⽂章的⽤户都会执⾏这段恶意JS。这个相对来说对我们开发⽹站来说不算重要，但是要⼩⼼攻击者在你⽹站注⼊⼀些⾮法代码，从⽽达到这个⽬的。Cookie劫持Cookie中⼀般保存了当前⽤户的登录凭证，如果可以得到，往往意味着可直接进⼊⽤户帐户，⽽Cookie劫持也是最常见的XSS攻击。以上⾯提过的反射型XSS的例⼦来说，可以像下⾯这样操作：⾸先诱使⽤户打开下⾯的链接：/?name=xss⽤户打开链接后，会加载，并执⾏中的代码。中存储了以下JS代码：var img = Element("img"); = "/log?" + escape();Child(img);上⾯的代码会向请求⼀张图⽚，但实际上是将当前页⾯的cookie发到了的服务器上。这样就完成了窃取cookie的过程。防御Cookie劫持的⼀个简单的⽅法是在Set-Cookie时加上HttpOnly标识，浏览器禁⽌JavaScript访问带HttpOnly属性的Cookie。XSS的防御1. 输⼊检查对输⼊数据做检查，⽐如⽤户名只允许是字母和数字，邮箱必须是指定格式。⼀定要在后台做检查，否则数据可能绕过前端检查直接发给服务器。⼀般前后端都做检查，这样前端可以挡掉⼤部分⽆效数据。对特殊字符做编码或过滤，但因为不知道输出时的语境，所以可能会做不适当的过滤，最好是在输出时具体情况具体处理。1. 输出检查对渲染到HTML中内容执⾏HtmlEncode，对渲染到JavaScript中的内容执⾏JavascriptEncode。另外还可以使⽤⼀些做XSS检查的开源项⽬。SQL注⼊SQL注⼊常常会听到，它与XSS类似，是由于⽤户提交的数据被当成命令来执⾏⽽造成的。下⾯是⼀个SQL注⼊的例⼦：String sql = "select * from user where username = '" + username + "'";像上⾯的SQL语句，如果⽤户提交的username参数是leo，则数据库执⾏的SQL为：select * from user where username = 'leo'但如果⽤户提交的username参数是leo’; drop table user–，那执⾏的SQL为：select * from user where username = 'leo'; drop table user--'在查询数据后，⼜执⾏了⼀个删除表的操作，这样的后果⾮常严重。博主本⼈的⽹站就是主要被SQL注⼊导致⽹站数据库受损SQL注⼊的防御防⽌SQL注⼊最好的⽅法是使⽤预编译语句，如下⾯所⽰：String sql = "select * from user where username = ?";PreparedStatement pstmt = eStatement(sql);ing(1, username);ResultSet results = eQuery();不同语⾔的预编译⽅法不同，但基本都可以处理。如果遇到⽆法使⽤预编译⽅法时，只能像防⽌XSS那样对参数进⾏检查和编码。博主后⾯会贴出⾃⼰完善项⽬的检测代码，就是对⽹站可以进⾏数据提交的表单的输⼊进⾏SQL语句检测。跨站请求伪造（CSRF）跨站请求伪造的英⽂全称是Cross Site Request Forgery，是由于操作所需的所有参数都能被攻击者得到，进⽽构造出⼀个伪造的请求，在⽤户不知情的情况下被执⾏。看下⾯⼀个例⼦：如果⽹站需要⽤户登录后可以删除博客，删除博客的请求地址如下：GET /blog/delete?id=1CSRF的防御1. 验证码CSRF是在⽤户不知情的情况下构造的⽹络情况，验证码则强制⽤户与应⽤交互，所以验证码可以很好得防⽌CSRF。但不能什么请求都加验证码。1. referer检查检查请求header中的referer也能帮助防⽌CSRF攻击，但服务器不是总能拿到referer，浏览器可能出于安全或隐私⽽不发送referer，所以也不常⽤。倒是图⽚防盗链中⽤得很多。1. Anti CSRF Token更多的是⽣成⼀个随机的token，在⽤户提交数据的同时提交这个token，服务器端⽐对后如果不正确，则拒绝执⾏操作。作为了解，⼀般前⾯的攻击都过了，就可以造成此类攻击。点击劫持（ClickJacking）点击劫持是从视觉上欺骗⽤户。攻击者使⽤⼀个透明的iframe覆盖在⼀个⽹页上，诱使⽤户在该⽹页上操作，⽽实际点击却是点在透明的iframe页⾯。点击劫持延伸出了很多攻击⽅式，有图⽚覆盖攻击、拖拽劫持等。点击劫持的防御针对iframe的攻击，可使⽤⼀个HTTP头：X-Frame-Options，它有三种可选值：DENY： 禁⽌任何页⾯的frame加载；SAMEORIGIN：只有同源页⾯的frame可加载；ALLOW-FROM：可定义允许frame加载的页⾯地址。针对图⽚覆盖攻击，则注意使⽤预防XSS的⽅法，防⽌HTML和JS注⼊。作为了解，⼀般前⾯的攻击都过了，就可以造成此类攻击。我的⽅法前⾔我们负责的团队项⽬为学校⽹站制作，所以涉及到⽤户输⼊的地⽅都在后台管理模块，从后台登录界⾯开始就应该做⼀些防护措施了。登录的字符检测function validate(value) { var pattern = /[`~!@#$%^&*()_+<>?:"{},.;'[]]/im; if (value === '' || value === null) return false; if ((value)) { alert("⾮法字符！"); return false; } return true;}function filterSqlStr(value) { var str = "and,delete,or,exec,insert,select,union,update,count,*,',join,>,<"; var sqlStr = (','); var flag = true;

for (var i = 0; i < ; i++) { if (rCase().indexOf(sqlStr[i]) != -1) { flag = false; break; } } alert(flag); return flag;}JS封装的2个⽅法，⽤于返回布尔值来判断是否通过。第⼀个为了过滤掉⾮法字符，第⼆个为了过滤有关数据库操作的⾮法字符。密码MD5加密//password Md5

public static String MD5Password(String oldstr) {

char hexDigits[] = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };

byte[] oldbytes = es();

try {

MessageDigest md = tance("MD5");// 获取对象

(oldbytes);// 初始化对象

byte[] newBytes = ();// 运⾏加密算法

char[] newStr = new char[32];

for (int i = 0; i < 16; i++) {

byte temp = newBytes[i];

newStr[2 * i] = hexDigits[temp >>> 4 & 0xf];

newStr[2 * i + 1] = hexDigits[temp & 0xf];

}

return new String(newStr);

} catch (NoSuchAlgorithmException e) {

return null;

}

}通过在后台对数据库中，管理员的密码进⾏MD5加密然后存⼊加密后的字段进去，在前台通过加密前的字段输⼊后在后台进⾏⽅法验证，实现MD5加密登录。防⽌数据库的密码被暴露查询出来。加密后⽆法被反解密出来。后台添加修改信息的字符检测同前台登录⼀样的检测⽅法，因为我只负责前台检测，如果⿊客绕过了我的检测，就要进⾏后台对数据传过去的值进⾏检测，这时候就是后台⼈员的⼯作了。所以前后台都要进⾏这些字符检测，但是后台的责任要重⼀点，因为数据最终流向是在后台服务器端，前台只是初步防护⽽已。验证码和滑块验证验证码字符验证⽬前验证码字符验证已经逐渐推出舞台，但是有⼀些专门这块验证服务的第三⽅平台，通过对验证码字符的不断改进和更新，对⼀些攻击者来说还是有防护作⽤，但是个⼈或企业⽹站还是⽤的⼀尘不变的验证⽅法的话，就很容易被攻击成功。很多初学者都在前台浏览器客户端⽤JS进⾏字符验证，很容易被破解跳过。好点的就在服务器进⾏检验，但是还是能被⼀些⿊客经过长期的经验发明的⼀些⼯具破解。这⾥就提及⼀下12306所推出的图⽚验证，⽬前已经被很多⼈报道也是不安全的，攻击者可以直接将图⽚处理后丢⼊google、百度的识图接⼝，返回的数值让⼈惊讶。居然能把第⼆张图识别为沙县⼩吃，我是觉得⽬前的⼈⼯智能的图像识别技术很厉害，所以要不了多久这种验证⽅式也会被淘汰，除⾮不断更新图⽚库。滑块验证滑块验证和12306的图⽚识别验证⽬前算是⽐较安全的验证⼿段，滑动验证的核⼼并不是简单的拼接成功就可以过，所以也不是简单的算⼀下偏移量就能破解。滑动验证做的好的是通过采集你的滑动过程轨迹与服务器端的海量样本进⾏对⽐，区分⼈还是机器，⽤到了很多深度学习的技术，当然市⾯上也有⼀些滑动验证只是前端拼接就能过，⼤家还是要多多研究⼀下。反正如果项⽬需要⽤到验证码这块，不能考虑只在客户端进⾏JS验证，客户端的JS验证有的前提下，还要把数据返回到后台来进⾏验证，这样可以⼤概率保证⽹站安全性，⽹站的攻防⼀直是持久的话题，没有绝对的安全也没有绝对的攻击。推荐⼤家多尝试⽹上的第三⽅服务商提供的验证服务，这样节省⾃⼰的精⼒来研究验证漏洞以及频繁的更新验证⽅法。End在校期间第⼀次认识到web安全重要性，⽬前只是初步的认识，如果后⾯了解了更多相关的知识，会继续做补充。关于hexo搭建的博客的技术应该不会再出什么⽂章了，有需要了解其他的知识的，会有困难的可以联系我或下⽅留⾔，然后看情况是否整理为⼀篇⽂章来集中回答帮助其他⼈。