标签:系统 access sign XML nload asc rip 代码 call
昨天本博客受到了xss跨站脚本注入攻击,3分钟攻陷……其实攻击者进攻的手法很简单,没啥技术含量。只能感叹自己之前竟然完全没防范。
这是数据库里留下的一些记录。最后那人弄了一个无线循环弹出框的脚本,估计这个脚本之后他再想输入也没法了。
类似这种:
<html>
<body onload=‘while(true){alert(1)}‘>
</body>
</html>
我立刻认识到这事件严重性,它说明我的博客有严重安全问题。因为xss跨站脚本攻击可能导致用户Cookie甚至服务器Session用户信息被劫持,后果严重。虽然攻击者就用些未必有什么技术含量的脚本即可做到。
第二天花些时间去了解,该怎么防范。顺便也看了sql注入方面。
sql注入是源于sql语句的拼接。所以需要对用户输入参数化。由于我使用的是jpa,不存在sql拼接问题,但还是对一些用户输入做处理比较好。我的博客系统并不复杂,一共四个表,Article,User,Message,Comment。
涉及数据库查询且由用户输入的就只有用户名,密码,文章标题。其它后台产生的如文章日期一类就不用管。
对于这三个字段的校验,可以使用自定义注解方式。
/**
* @ClassName: IsValidString
* @Description: 自定义注解实现前后台参数校验,判断是否包含非法字符
* @author 无名
* @date 2016-7-25 下午8:22:58
* @version 1.0
*/
@Target({ElementType.FIELD, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = IsValidString.ValidStringChecker.class)
@Documented
public @interface IsValidString
{
String message() default "The string is invalid.";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default{};
class ValidStringChecker implements ConstraintValidator<IsValidString,String>
{
@Override
public void initialize(IsValidString arg0)
{
}
@Override
public boolean isValid(String strValue, ConstraintValidatorContext context)
{
//校验方法
return true;
}
}
}
定义了自定义注解以后就可以在对应的实体类字段上添上@IsValidString即可。
但由于我还没研究出怎么拦截自定义注解校验返回的异常,就在controller类里做校验吧。
public static boolean contains_sqlinject_illegal_ch(String str_input) {
//"[`~!@#$%^&*()+=|{}‘:;‘,\\[\\].<>/?~!@#¥%……&*()——+|{}【】‘;:”“’。,、?]"
String regEx = "[‘=<>;\"]";
Pattern p = Pattern.compile(regEx);
Matcher m = p.matcher(str_input);
if (m.find()) {
return true;
} else {
return false;
}
}
拦截的字符有 ‘ " [] <> ;
我觉得这几个就够了吧。<>顺便就解决了xxs跨站脚本注入问题。
而xxs跨站脚本注入问题还是让我很头疼。因为我的博客系统使用wangEditor web文本编辑器,返回给后台的包含很多合法的html标签,用来表现文章格式。所以不能统一过滤<>这类字符。
例如,将<html><body onload=‘while(true){alert(1)}‘></body></html>这句输入编辑器,提交。后台得到的是:
中间被转意的<,>是合法的可供页面显示的<>字符。而外面的<p><br>就是文本编辑器生产的用来控制格式的正常的html标签。
问题在于,如果有人点击编辑器“源代码”标识,将文本编辑器生产的正常的html标签,再输入这句<html><body onload=‘while(true){alert(1)}‘></body></html>结果返回后台的就是原封不动的<html><body onload=‘while(true){alert(1)}‘></body></html> <和>没有变成<和>。
这让人头痛,我在想这个编辑器为什么提供什么狗屁查看源代码功能,导致不能统一对<>,有毛病。
在这种情况下,我只能过滤一部分认准是有危害的html标签,而众所周知,这类黑名单校验是不够安全的。
/*
* Cross-site scripting (XSS) is a type of computer security vulnerability
* typically found in web applications. XSS enables attackers to inject
* client-side scripts into web pages viewed by other users. A cross-site
* scripting vulnerability may be used by attackers to bypass access
* controls such as the same-origin policy. Cross-site scripting carried out
* on websites accounted for roughly 84% of all security vulnerabilities
* documented by Symantec as of 2007. Their effect may range from a petty
* nuisance to a significant security risk, depending on the sensitivity of
* the data handled by the vulnerable site and the nature of any security
* mitigation implemented by the site‘s owner.(From en.wikipedia.org)
*/
public static boolean contains_xss_illegal_str(String str_input) {
if (str_input.contains("<html") || str_input.contains("<HTML")
|| str_input.contains("<body") || str_input.contains("<BODY")
|| str_input.contains("<script")
|| str_input.contains("<SCRIPT") || str_input.contains("<link")
|| str_input.contains("<LINK")
|| str_input.contains("%3Cscript")
|| str_input.contains("%3Chtml")
|| str_input.contains("%3Cbody")
|| str_input.contains("%3Clink")
|| str_input.contains("%3CSCRIPT")
|| str_input.contains("%3CHTML")
|| str_input.contains("%3CBODY")
|| str_input.contains("%3CLINK") || str_input.contains("<META")
|| str_input.contains("<meta") || str_input.contains("%3Cmeta")
|| str_input.contains("%3CMETA")
|| str_input.contains("<style") || str_input.contains("<STYLE")
|| str_input.contains("%3CSTYLE")
|| str_input.contains("%3Cstyle") || str_input.contains("<xml")
|| str_input.contains("<XML") || str_input.contains("%3Cxml")
|| str_input.contains("%3CXML")) {
return true;
} else {
return false;
}
}
我在考虑着把这个文本编辑器的查看源代码功能给干掉。
另外,还是要系统学习xss跨站脚本注入防范。开始看一本书《白帽子讲web安全》,觉得这本书不错。
到时候有新见解再在这篇文章补充。
标签:系统 access sign XML nload asc rip 代码 call
原文地址:http://www.cnblogs.com/rixiang/p/6234997.html