来场战争如何？Java开发必须掌握的8种网站***技术

时间 2019-11-18

标签战争如何 java 开发必须掌握网站技术栏目 Java 繁體版

原文原文链接

XSS

XSS的全称是跨站脚本(Cross Site Scripting),是WEB应用程序中最多见到的手段之一。跨站脚本指的是者在网页中嵌入恶意脚本程序, 当用户打开该网页时,脚本程序便开始在客户端的浏览器上执行,以盗取客户端cookie、盗取用户名密码、下载执行病毒程序等等。java

为了避免和层叠样式表 (Cascading Style Sheets,CSS)的缩写混淆,故将跨站脚本缩写为XSSsql

有一种场景,用户在表单上输入一段数据后,提交给服务端进行持久化,其余页面上须要从服务端将数据取出来展现。仍是使用以前那个表单nick,用户输入昵称以后,服务端会将nick保存,并在新的页面展示给用户,当普通用户正常输入hollis,页面会显示用户的 nick为hollis:数据库

<body> 
   hollis
</body>

可是,若是用户输入的不是一段正常的nick字符串,而是<script>alert("haha")</script>, 服务端会将这段脚本保存起来,当有用户查看该页面时,页面会出现以下代码:编程

<body> 
   <script>
       alert("haha")
   </script>
</body>

其影响就是可能会在页面直接弹出对话框。后端

XSS的防护

XSS之因此会发生,是由于用户输入的数据变成了代码。所以,咱们须要对用户输入的数据进行HTML转义处理,将其中的“尖括号”、“单引号”、“引号” 之类的特殊字符进行转义编码。浏览器

现在不少开源的开发框架自己默认就提供HTML代码转义的功能,如流行的jstl、Struts等等,不须要开发人员再进行过多的开发。使用jstl标签进行HTML转义,将变量输出,代码以下:缓存

<c:out value="${nick}" escapeXml="true"></c:out>安全

只须要将escapeXml设置为true, jstl就会将变量中的HTML代码进行转义输出。服务器

CSRF

CSRF的全称是跨站请求伪造(cross site request forgery), 是一种对网站的恶意利用,你能够这么理解CSRF者盗用了你的身份,以你的名义向第三方网站发送恶意请求。CRSF能作的事情包括利用你的身份发邮件、发短信、进行交易转帐等等,甚至盗取你的帐号。cookie

尽管听起来跟XSS跨站脚本有点类似,但事实上CSRF与XSS差异很大,XSS利用的是站点内的信任用户,而CSRF则是经过假装来自受信任用户的请求来利用受信任的网站。

假设某银行网站A,他以GET请求来发起转帐操做,转帐的地址为www.xxx.com/transfer.do?accountNum=10001&money=10000,accountNum参数表示转帐的目的帐户,money参数表示转帐金额。而某大型论坛B上,一个恶意用户上传了一张图片,而图片的地址栏中填的并非图片的地址,而是前面所说的转帐地址:

<img src="http://www.xxx.com/transfer.do?accountNum=10001&money=10000">

当你登录网站A后,没有及时登出,这个时候你访问了论坛B,不幸的事情发生了,你会发现你的帐户里面少了10000块......

为何会这样呢,在你登录银行A的时候,你的浏览器端会生成银行A的cookie,而当你访问论坛B的时候,页面上的<img>标签须要浏览器发起一个新的HTTP请求,以得到图片资源, 当浏览器发起请求的时候,请求的倒是银行A的转帐地址www.xxx.com/transfer.do?accoun tNum=10001&money=10000,而且会带上银行A的cookie信息,结果银行的服务器收到这个请求后,会认为是你发起的一次转帐操做,所以你的帐户里边便少了10000块。

CSRF的防护

cookie设置为HttpOnly
CSRF很大程度上是利用了浏览器的cookie,为了防止站内的XSS漏洞盗取cookie,须要在cookie中设置"HttpOnly"属性,这样经过程序(如JavascriptS脚本、Applet等)就没法读取到cookie信息,避免了者伪造cookie的状况出现。

增长token
CSRF之因此可以成功,是由于者能够伪造用户的请求,该请求中全部的用户验证信息都存在于cookie中,所以者能够在不知道用户验证信息的状况下直接利用用户的cookie来经过安全验证。由此可知,抵御CSRF的关键在于:在请求中放入者所不能伪造的信息,而且该信息不存在于cookie之中。鉴于此,系统开发人员能够在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端进行token校验,若是请求中没有token或者token内容不正确,则认为是CSRF而拒绝该请求。

经过Referer识别
根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在一般状况下,访问一个安全受限页面的请求都来自于同一个网站。好比某银行的转帐是经过用户访问http://www.xxx.com/transfer.do页面完成,用户必须先登陆www.xxx.com,而后经过点击页面上的提交按钮来触发转帐事件。当用户提交请求时,该转帐请求的Referer值就会是提交按钮所在页面的URL(本例为www.xxx.com/transfer.do)。若是者要对银行网站实施CSRF,他只能在其余的网站构造请求,当用户经过其余网站发送请求到银行时,该请求的Referer的值是其余网站的地址,而不是银行转帐页面的地址。所以,要防护CSRF,银行网站只须要对于每个转帐请求验证其Referer值,若是是以www.xxx.com域名开头的地址,则说明该请求是来自银行网站本身的请求,是合法的。若是 Referer是其余网站的话,就有多是CSRF,则拒绝该请求。

SQL注入

所谓SQL注入,就是经过把SQL命令假装成正常的HTTP请求参数,传递到服务端,欺骗服务器最终执行恶意的SQL命令,达到目的。者能够利用SQL注入漏洞,查询非受权信息, 修改数据库服务器的数据,改变表结构,甚至是获取服务器root权限。总而言之,SQL注入漏洞的危害极大,者采用的SQL指令,决定的威力。当前涉及到大批量数据泄露的事件,大部分都是经过利用SQL注入来实施的。

假设有个网站的登陆页面,以下所示:

假设用户输入nick为zhangsan,密码为password1,则验证经过,显示用户登陆:

不然,显示用户没有登陆:

SQL注入原理

**下面是一段普通的JDBC的Java代码，这段代码就能够被利用，进行SQL注入*：

Connection conn = getConnection();
String sql = "select * from hhuser where nick = '" + nickname + "'" + " and passwords = '" + password + "'"; 
Statement st = (Statement) conn.createStatement();
ResultSet rs = st.executeQuery(sql);
List<UserInfo> userInfoList = new ArrayList<UserInfo>(); 
while (rs.next()) {
UserInfo userinfo = new UserInfo();         
userinfo.setUserid(rs.getLong("userid"));       
userinfo.setPasswords(rs.getString("passwords"));       
userinfo.setNick(rs.getString("nick"));         
userinfo.setAge(rs.getInt("age"));      
userinfo.setAddress(rs.getString("address"));       
userInfoList.add(userinfo);
}

当用户输入nick为zhangsan,密码为' or '1'='1的时候,意想不到的事情出现了,页面显示为login状态:

当用户在密码栏输入“' or '1'='1”后，代码中的SQL语句就会被拼接成：

"select * from hhuser user where nick = 'zhangsan' and passwords = '' or '1'='1'"，由于or后面的1=1是恒为true的，因此，该语句的执行结果就会有正常的数据返回。从而绕过密码校验。

以上即是一次简单的、典型的SQL注入。固然,SQL注入的危害不只如此,假设用户输入用户名zhangsan,在密码框输入' ;drop table aaa;-- 会发生什么呢?

SQL注入的防护

使用预编译语句
预编译语句PreparedStatement是java.sql中的一个接口,继承自Statement接口。经过 Statement对象执行SQL语句时,须要将SQL语句发送给DBMS,由DBMS先进行编译后再执行。而预编译语句和Statement不一样,在建立PreparedStatement对象时就指定了SQL语句,该语句当即发送给DBMS进行编译,当该编译语句须要被执行时,DBMS直接运行编译后的SQL语句,而不须要像其余SQL语句那样首先将其编译。

前面介绍过,引起SQL注入的根本缘由是恶意用户将SQL指令假装成参数传递到后端数据库执行, 做为一种更为安全的动态字符串的构建方法,预编译语句使用参数占位符来替代须要动态传入的参数,这样者没法改变SQL语句的结构,SQL语句的语义不会发生改变,即使用户传入相似于前面' or '1'='1这样的字符串,数据库也会将其做为普通的字符串来处理。

使用ORM框架
由上文可见,防止SQL注入的关键在于对一些关键字符进行转义,而常见的一些ORM框架,如 ibatis、hibernate等,都支持对相应的关键字或者特殊符号进行转义,能够经过简单的配置, 很好的预防SQL注入漏洞,下降了普通的开发人员进行安全编程的门槛。 Ibatis的insert语句配置:

<insert id="insert" parameterClass="userDO">
insert into users(gmt_create,gmt_modified,userid,user_nick,address,age,sex) values(now(),now(),#userId#,#userNick#,#address#,#age#,#sex#)
</insert>
经过#符号配置的变量,ibatis可以对输入变量的一些关键字进行转义,防止SQL注入***。

避免密码明文存放
对存储的密码进行单向Hash,如使用MD5对密码进行摘要,而非直接存储明文密码,这样的好处就是万一用户信息泄露,即圈内所说的被“”,没法直接获取用户密码,而只能获得一串跟密码相差十万八千里的Hash码。

处理好相应的异常
后台的系统异常,极可能包含了一些如服务器版本、数据库版本、编程语言等等的信息,甚至是数据库链接的地址及用户名密码,者能够按图索骥,找到对应版本的服务器漏洞或者数据库漏洞进行,所以,必需要处理好后台的系统异常,重定向到相应的错误处理页面,而不是任由其直接输出到页面上。

上传文件漏洞

在上网的过程当中,咱们常常会将一些如图片、压缩包之类的文件上传到远端服务器进行保存, 文件上传指的是恶意者利用一些站点没有对文件的类型作很好的校验这样的漏洞, 上传了可执行的文件或者脚本,而且经过脚本得到服务器上相应的权利,或者是经过诱导外部用户访问或者下载上传的病毒或者文件,达到目的。

为了防范用户上传恶意的可执行文件和脚本,以及将文件上传服务器当作免费的文件存储服务器使用,须要对上传的文件类型进行白名单(非黑名单,这点很是重要)校验,而且限制上传文件的大小,上传的文件,须要进行从新命名,使者没法猜想到上传文件的访问路径。

对于上传的文件来讲,不能简单的经过后缀名称来判断文件的类型,由于恶意能够将可执行文件的后缀名称改为图片或者其余的后缀类型,诱导用户执行。所以,判断文件类型须要使用更安全的方式。不少类型的文件,起始的几个字节内容是固定的,所以,根据这几个字节的内容,就能够肯定文件类型,这几个字节也被称为魔数(magic number)。

DDoS

DDoS(Distributed Denial of Service),即分布式拒绝服务,是目前最为强大、最难以防护的方式之一。前不久（2018-03-01），GitHub就遭受了一次比较严重的DDoS，个人文章《GitHub遭受的DDoS究竟是个什么鬼？》中有关于此次和DDoS的详细介绍。这里再也不赘述。

DDoS的有不少种类型,如依赖蛮力的ICMP Flood、UDP Flood等等,随着硬件性能的提高,须要的机器规模愈来愈大,组织大规模的愈来愈困难,如今已经不常见,还有就是依赖协议特征以及具体的软件漏洞进行的,如Slowloris,Hash碰撞等等,这类主要利用协议以及软件漏洞发起,须要在特定环境下才会出现,更多的者采用的是前面两种的混合方式,即利用了协议、系统的缺陷,又具有了海量的流量, 如SYN Flood、DNS Query Flood等等。

DNS Query Flood

DNS Query Flood其实是UDP Flood的一种变形,因为DNS服务在互联网中不可替代的做用,一旦DNS服务器瘫痪,影响甚大。

DNS Query Flood采用的方法是向被的服务器发送海量的域名解析请求,一般,请求解析的域名是随机生成,大部分根本就不存在,而且经过伪造端口和客户端IP,防止查询请求被ACL过滤。被的DNS服务器在接收到域名解析请求后,首先会在服务器上查找是否有对应的缓存, 因为域名是随机生成的,几乎不可能有相应的缓存信息,当没有缓存,而且该域名没法直接由该DNS服务器进行解析的时候,DNS服务器会向其上层DNS服务器递归查询域名信息,直到全球互联网的13台根DNS服务器。大量不存在的域名解析请求,给服务器带来了很大的负载,当解析请求超过必定量的时候,就会形成DNS服务器解析域名超时,这样者便达成了目的。

CC

CC(Challenge Collapsar)属于DDoS的一种,是基于应用层HTTP协议发起的DDos,也被称为HTTP Flood。

CC的原理是这样的,者经过控制的大量“肉鸡”或者利用从互联网上搜寻的大量匿名的HTTP代理,模拟正经常使用户给网站发起请求直到该网站拒绝服务为止。大部分网站会经过CDN以及分布式缓存来加快服务端响应,提高网站的吞吐量,而这些精心构造的HTTP请求每每有意避开这些缓存,须要进行屡次DB查询操做或者是一次请求返回大量的数据,加速系统资源消耗,从而拖垮后端的业务处理系统,甚至连相关存储以及日志收集系统也没法幸免。

最后

喜欢的能够关注个人公众号，java小瓜哥的分享平台，平时整理的资料都放在里面了