XSS
XSS stands for cross-site scripting (Cross Site Scripting), it is one of the means WEB application most commonly seen. Cross-site scripting refers to embed malicious script in a Web page, when the user opens the page, the script begins execution on the client's browser to steal a client cookie, steal username and password to download for viruses procedures.
In order not to abbreviations and Cascading Style Sheets (Cascading Style Sheets, CSS) confusion, it will be abbreviated as XSS Cross Site Scripting
There is a scene, after the user enters some data on the form, submitted for persistence to the server, the server will require from data taken out show on other pages. Before using the form or nick, after the user enter a nickname, the server will nick save and the new page presented to the user, when the normal average user input hollis, the page will display the user's nick is hollis:
<body>
hollis
</body>However, if the user input is not normal for a string of nick, but <script> alert ( "haha") </ script>, the server will save this script up, when users view the page, the page will It appears the following code:
<body>
<script>
alert("haha")
</script>
</body>Its impact is likely to be directly in the pop-up dialog page.
XSS defense
XSS reason happens because the data entered by the user into a code. Therefore, we need the data entered by the user HTML escaping the special characters of "angle brackets", "single quotes", "quotes" like the escape code.
Today, many open-source development framework itself provides default HTML code escaping functions, such as the popular jstl, Struts, etc., developers do not need too much further development. HTML tags using jstl escape output variables, as follows:
<c:out value="${nick}" escapeXml="true"></c:out>
EscapeXml only need to be set to true, jstl will be variable in HTML code to escape output.
CSRF
CSRF stands for CSRF (cross site request forgery), it is a malicious use of the website, so you can understand CSRF who stole your identity, in your name to send malicious requests to third-party websites. CRSF can do your identity, including the use of e-mail, text messaging, transaction transfers, etc., and even steal your account.
Although it sounds a bit similar with the cross-site scripting XSS, CSRF and XSS but in fact a great difference, XSS exploit the trust a user within the site, while CSRF is by pretending to be a trusted user's request to use a trusted site from.
Suppose a bank site A, he GET request to initiate the transfer operation, the transfer of address indicates the destination account transfer is www.xxx.com/transfer.do?accountNum=10001&money=10000,accountNum parameter, money transfer amount parameter represents. And on a large forum B, a malicious user to upload a picture, and the picture is not the picture fill the address bar address, but said earlier transfer Address:
<img src="http://www.xxx.com/transfer.do?accountNum=10001&money=10000">
When you visit the Web site A, there is no time out, this time you visit the forum B, unfortunate things happen, you will find less 10000 Your account inside ......
Why is this so, when you log in Bank A, your browser will generate a cookie Bank A, and when you visit the forum of B, <img> tag you need to initiate a new HTTP request on the page to get the picture resources, when the browser that initiated the request, but the request is the transfer address Bank a www.xxx.com/transfer.do?accoun tNum = 10001 & money = 10000, and will bring Bank a cookie information, after the results of the bank's server receives the request, you will be considered to be initiated once the transfer operation, so you will be less inside account 10000.
CSRF defense
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 The principle is this, who controlled through a lot of "chicken" or use the search from the Internet a lot of anonymous HTTP proxy, simulate normal user initiates a request to the site until the site so far refused service. Most sites will be speed up by CDN and distributed cache server response, enhance the throughput of the site, which crafted HTTP requests often eschewed these caches, require multiple DB query or a request to return a large number of data, speed up system resources consumption, and thus caused the collapse of the back-end business processing system, storage, and even the relevant log collection system can not be spared.
At last
Like you can focus on my public number, java small Guage sharing platform, usually finishing materials are placed inside