17Qubuntu 防火?/a>
16Qubuntu 开?ssh 服务
15Qubuntu jdk 安装与配|?/a>
14Qubuntu tomcat 安装与配|?/a>
13Qubuntu mysql 安装
12Qubuntu root ?user 用户切换
11Qlinux more 命o
10Qlinux tar 命o
09Qlinux chmod 命o
08Qlinux touch 命o
07Qlinux cat 命o
06Qlinux mv 命o
05Qlinux rm 命o
04Qlinux cp 命o
03Qlinux mkdir 命o
02Qlinux cd 命o
01Qlinux ls 命o
]]>
]]>
package com.qiyi.appstore.util;
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import org.apache.commons.beanutils.BeanUtils;
import org.apache.commons.lang.StringUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import com.qiyi.appstore.exception.AppStoreException;
import com.qiyi.cloud.user.ApiCode;
public class XssUtils {
private static final Logger logger=LoggerFactory.getLogger(XssUtils.class);
public static String getSafeStringXSS(String s){
if (StringUtils.isBlank(s)) {
return s;
}
StringBuilder sb = new StringBuilder(s.length() + 16);
for (int i = 0; i < s.length(); i++) {
char c = s.charAt(i);
switch (c) {
case '<':
sb.append("<");
break;
case '>':
sb.append(">");
break;
case '\'':
sb.append("′");// ´");
break;
case '′':
sb.append("′");// ´");
break;
case '\"':
sb.append(""");
break;
case 'Q?:
sb.append(""");
break;
case '&':
sb.append("Q?);
break;
case '#':
sb.append("Q?);
break;
case '\\':
sb.append('K?);
break;
case '=':
sb.append("=");
break;
default:
sb.append(c);
break;
}
}
return sb.toString();
}
public static <T> void getXssSaftBean(Class<?> clz,T bean) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException{
String classname = clz.getSimpleName();
logger.info("map target class name is {} .",classname);
Field[] fields = clz.getDeclaredFields();
for(Field field : fields){
Class<?> type = field.getType();
if(type.equals(String.class)){
String fieldname = field.getName();
String value = BeanUtils.getProperty(bean, fieldname);
if(StringUtils.isNotBlank(value)){
BeanUtils.setProperty(bean, fieldname, getSafeStringXSS(value));
}
}
}
}
}
]]>
使用aprcd 可以让tomcat的性能提升???
目前目中都使用q样的配|?br />
<Connector port="8080" protocol="org.apache.coyote.http11.Http11AprProtocol" URIEncoding="UTF-8"
enableLookups="false"
acceptCount="300"
connectionTimeout="20000"
disableUploadTimeout="true" maxThreads="1000" maxSpareThreads="50" minSpareThreads="25"
redirectPort="8443" />
catalia.sh
catalia.sh
CATALINA_OPTS="$CATALINA_OPTS -Djava.library.path=/usr/local/apr/lib"
]]>
]]>
CSRFQCross Site Request Forgery, 跨站域请求伪造）是一U网l的d方式Q它?2007 q曾被列Z联网 20 大安全隐患之一。其他安全隐患，比如 SQL 脚本注入Q跨站域脚本d{在q年来已l逐渐Z人熟知，很多|站也都针对他们q行了防御。然而，对于大多Ch来说QCSRF 却依然是一个陌生的概念。即便是大名鼎鼎?Gmail, ?2007 q底也存在着 CSRF 漏洞Q从而被黑客d而 Gmail 的用户造成巨大的损失?/p>
CSRF d实例
CSRF d可以在受完毫不知情的情况下以受害者名义伪造请求发送给受攻ȝ点，从而在q未授权的情况下执行在权限保护之下的操作。比如说Q受完?Bob 在银行有一W存ƾ，通过寚w行的|站发送请?http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以?Bob ?1000000 的存ƾ{?bob2 的̎号下。通常情况下，该请求发送到|站后，服务器会先验证该h是否来自一个合法的 sessionQƈ且该 session 的用?Bob 已经成功登陆。黑?Mallory 自己在该银行也有账户Q他知道上文中的 URL 可以把钱q行转帐操作。Mallory 可以自己发送一个请求给银行Qhttp://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来?Mallory 而非 BobQ他不能通过安全认证Q因此该h不会起作用。这ӞMallory 惛_使用 CSRF 的攻L式，他先自己做一个网站，在网站中攑օ如下代码Q?src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”Qƈ且通过q告{诱?Bob 来访问他的网站。当 Bob 讉K该网站时Q上q?url ׃?Bob 的浏览器发向银行Q而这个请求会附带 Bob 览器中?cookie 一起发向银行服务器。大多数情况下，该请求会p|Q因Z要求 Bob 的认证信息。但是，如果 Bob 当时恰y刚访问他的银行后不久Q他的浏览器与银行网站之间的 session 未q期Q浏览器?cookie 之中含有 Bob 的认证信息。这Ӟ悲剧发生了，q个 url h׃得到响应Q钱从 Bob 的̎可{Ud Mallory 的̎P?Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即他去银行查询日志Q他也只能发现确实有一个来自于他本人的合法h转移了资金，没有M被攻ȝ痕迹。?Mallory 则可以拿到钱后逍遥法外?/p>
CSRF d的对?/strong>
在讨论如何抵?CSRF 之前Q先要明?CSRF d的对象，也就是要保护的对象。从以上的例子可知，CSRF d是黑客借助受害者的 cookie 骗取服务器的信QQ但是黑客ƈ不能拿到 cookieQ也看不?cookie 的内宏V另外，对于服务器返回的l果Q由于浏览器同源{略的限Ӟ黑客也无法进行解析。因此，黑客无法从返回的l果中得CQ何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的|而非H取服务器中的数据。所以，我们要保护的对象是那些可以直接生数据改变的服务Q而对于读取数据的服务Q则不需要进?CSRF 的保护。比如银行系l中转̎的请求会直接改变账户的金额，会遭?CSRF dQ需要保护。而查询余额是寚w额的d操作Q不会改变数据，CSRF d无法解析服务器返回的l果Q无需保护?/p>
当前防M CSRF 的几U策?/strong>
在业界目前防?CSRF d主要有三U策略：验证 HTTP Referer 字段Q在h地址中添?token q证；?HTTP 头中自定义属性ƈ验证。下面就分别对这三种{略q行详细介绍?/p>
验证 HTTP Referer 字段
Ҏ HTTP 协议Q在 HTTP 头中有一个字D叫 RefererQ它记录了该 HTTP h的来源地址。在通常情况下，讉K一个安全受限页面的h来自于同一个网站，比如需要访?http://bank.example/withdraw?account=bob&amount=1000000&for=MalloryQ用户必d登陆 bank.exampleQ然后通过点击面上的按钮来触发{账事件。这Ӟ该{帐请求的 Referer 值就会是转̎按钮所在的面?URLQ通常是以 bank.example 域名开头的地址。而如果黑客要寚w行网站实?CSRF dQ他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行Ӟ该请求的 Referer 是指向黑客自q|站。因此，要防?CSRF dQ银行网站只需要对于每一个{账请求验证其 Referer |如果是以 bank.example 开头的域名Q则说明该请求是来自银行|站自己的请求，是合法的。如?Referer 是其他网站的话，则有可能是黑客的 CSRF dQ拒l该h?/p>
q种Ҏ的显而易见的好处是单易行，|站的普通开发h员不需要操?CSRF 的漏z，只需要在最后给所有安全敏感的hl一增加一个拦截器来检?Referer 的值就可以。特别是对于当前现有的系l，不需要改变当前系l的M已有代码和逻辑Q没有风险，非常便捷?/p>
然而，q种Ҏq万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个览器对?Referer 的具体实现可能有差别Qƈ不能保证览器自w没有安全漏z。用验?Referer 值的ҎQ就是把安全性都依赖于第三方Q即览器）来保障，从理Z来讲Q这样ƈ不安全。事实上Q对于某些浏览器Q比?IE6 ?FF2Q目前已l有一些方法可以篡?Referer 倹{如?bank.example |站支持 IE6 览器，黑客完全可以把用h览器?Referer DZ bank.example 域名开头的地址Q这样就可以通过验证Q从而进?CSRF d?/p>
即便是用最新的览器，黑客无法改 Referer |q种Ҏ仍然有问题。因?Referer g记录下用L讉K来源Q有些用戯样会늊C们自q隐私权，特别是有些组l担?Referer g把组l内|中的某些信息泄露到外网中。因此，用户自己可以讄览器其在发送请求时不再提供 Referer。当他们正常讉K银行|站Ӟ|站会因求没?Referer D认为是 CSRF dQ拒l合法用L讉K?/p>
在请求地址中添?token q?/strong>
CSRF d之所以能够成功，是因为黑客可以完全伪造用LhQ该h中所有的用户验证信息都是存在?cookie 中，因此黑客可以在不知道q些验证信息的情况下直接利用用户自己?cookie 来通过安全验证。要抵M CSRFQ关键在于在h中放入黑客所不能伪造的信息Qƈ且该信息不存在于 cookie 之中。可以在 HTTP h中以参数的Ş式加入一个随Z生的 tokenQƈ在服务器端徏立一个拦截器来验证这?tokenQ如果请求中没有 token 或?token 内容不正，则认为可能是 CSRF d而拒l该h?/p>
q种Ҏ要比?Referer 要安全一些，token 可以在用L陆后产生q放?session 之中Q然后在每次h时把 token ?session 中拿出，与请求中?token q行比对Q但q种Ҏ的难点在于如何把 token 以参数的形式加入h。对?GET hQtoken 附在请求地址之后Q这?URL 变?http://url?csrftoken=tokenvalue?而对?POST h来说Q要?form 的最后加?<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>Q这样就?token 以参数的形式加入h了。但是，在一个网站中Q可以接受请求的地方非常多，要对于每一个请求都加上 token 是很ȝ的，q且很容易漏掉，通常使用的方法就是在每次面加蝲Ӟ使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a ?form 标签后加?token。这样可以解军_部分的请求，但是对于在页面加载之后动态生成的 html 代码Q这U方法就没有作用Q还需要程序员在编码时手动d token?/p>
该方法还有一个缺Ҏ难以保证 token 本n的安全。特别是在一些论坛之cL持用戯己发表内容的|站Q黑客可以在上面发布自己个h|站的地址。由于系l也会在q个地址后面加上 tokenQ黑客可以在自己的网站上得到q个 tokenQƈ马上可以发?CSRF d。ؓ了避免这一点，pȝ可以在添?token 的时候增加一个判断，如果q个链接是链到自己本站的Q就在后面添?tokenQ如果是通向外网则不加。不q，即ɘq个 csrftoken 不以参数的Ş式附加在h之中Q黑客的|站也同样可以通过 Referer 来得到这?token g发动 CSRF d。这也是一些用户喜Ƣ手动关闭浏览器 Referer 功能的原因?/p>
?HTTP 头中自定义属性ƈ验证
q种Ҏ也是使用 token q进行验证，和上一U方法不同的是，q里q不是把 token 以参数的形式|于 HTTP h之中Q而是把它攑ֈ HTTP 头中自定义的属性里。通过 XMLHttpRequest q个c，可以一ơ性给所有该c请求加?csrftoken q个 HTTP 头属性，q把 token 值放入其中。这栯决了上种Ҏ在请求中加入 token 的不便，同时Q通过 XMLHttpRequest h的地址不会被记录到览器的地址栏，也不用担?token 会透过 Referer 泄露到其他网站中厅R?/p>
然而这U方法的局限性非常大。XMLHttpRequest h通常用于 Ajax Ҏ中对于页面局部的异步hQƈ非所有的h都适合用这个类来发P而且通过该类h得到的页面不能被览器所记录下，从而进行前q，后退Q刷斎ͼ收藏{操作，l用户带来不ѝ另外，对于没有q行 CSRF 防护的遗留系l来_要采用这U方法来q行防护Q要把所有请求都改ؓ XMLHttpRequest hQ这样几乎是要重写整个网站，q代h疑是不能接受的?/p>
Java 代码CZ
下文以 Java ZQ对上述三种Ҏ分别用代码进行示例。无Z用何U方法，在服务器端的拦截器必不可，它将负责查到来的h是否W合要求Q然后视l果而决定是否l请求或者丢弃。在 Java 中，拦截器是?Filter 来实现的。我们可以编写一?FilterQƈ?web.xml 中对其进行配|，使其对于讉K所有需?CSRF 保护的资源的hq行拦截?/p>
?filter 中对h?Referer 验证代码如下
清单 1. ?Filter 中验?Referer
|
1
2
3
4
5
6
7
8 |
// ?HTTP 头中取得 Referer ? String referer=request.getHeader("Referer"); // 判断 Referer 是否?bank.example 开? if((referer!=null) &&(referer.trim().startsWith(“bank.example”))){ chain.doFilter(request, response); }else{ request.getRequestDispatcher(“error.jsp”).forward(request,response); } |
以上代码先取?Referer |然后q行判断Q当光Iƈ?bank.example 开头时Q则l箋hQ否则的话可能是 CSRF dQ{?error.jsp 面?/p>
如果要进一步验证请求中?token |代码如下
|
1 |
<em><strong>清单 2. ?filter 中验证请求中?lt;/strong></em> token |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 |
HttpServletRequest req = (HttpServletRequest)request; HttpSession s = req.getSession(); // ?session 中得?csrftoken 属? String sToken = (String)s.getAttribute(“csrftoken”); if(sToken == null){ // 产生新的 token 攑օ session ? sToken = generateToken(); s.setAttribute(“csrftoken”,sToken); chain.doFilter(request, response); } else{ // ?HTTP 头中取得 csrftoken String xhrToken = req.getHeader(“csrftoken”); // 从请求参C取得 csrftoken String pToken = req.getParameter(“csrftoken”); if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){ chain.doFilter(request, response); }else if(sToken != null && pToken != null && sToken.equals(pToken)){ chain.doFilter(request, response); }else{ request.getRequestDispatcher(“error.jsp”).forward(request,response); } } |
首先判断 session 中有没有 csrftokenQ如果没有，则认为是W一ơ访问，session 是新建立的，q时生成一个新?tokenQ放?session 之中Qƈl箋执行h。如?session 中已l有 csrftokenQ则说明用户已经与服务器之间建立了一个活跃的 sessionQ这时要看这个请求中有没有同旉带这?tokenQ由于请求可能来自于常规的访问或?XMLHttpRequest 异步讉KQ我们分别尝试从h中获?csrftoken 参数以及?HTTP 头中获取 csrftoken 自定义属性ƈ?session 中的D行比较，只要有一个地方带有有?tokenQ就判定h合法Q可以l执行，否则p{到错误页面。生?token 有很多种ҎQQ何的随机法都可以用，Java ?UUID cM是一个不错的选择?/p>
除了在服务器端利?filter 来验?token 的g外，我们q需要在客户端给每个h附加上这?tokenQ这是利?js 来给 html 中的链接和表单请求地址附加 csrftoken 代码Q其中已定义 token 为全局变量Q其值可以从 session 中得到?/p>
|
1 |
<em><strong>清单 3. 在客L对于h附加</strong> </em>token |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62 |
function appendToken(){ updateForms(); updateTags(); } function updateForms() { // 得到面中所有的 form 元素 var forms = document.getElementsByTagName('form'); for(i=0; i<forms.length; i++) { var url = forms[i].action; // 如果q个 form ?action gؓI，则不附加 csrftoken if(url == null || url == "" ) continue; // 动态生?input 元素Q加入到 form 之后 var e = document.createElement("input"); e.name = "csrftoken"; e.value = token; e.type="hidden"; forms[i].appendChild(e); } } function updateTags() { var all = document.getElementsByTagName('a'); var len = all.length; // 遍历所?a 元素 for(var i=0; i<len; i++) { var e = all[i]; updateTag(e, 'href', token); } } function updateTag(element, attr, token) { var location = element.getAttribute(attr); if(location != null && location != '' '' ) { var fragmentIndex = location.indexOf('#'); var fragment = null; if(fragmentIndex != -1){ //url 中含有只相当늚锚标? fragment = location.substring(fragmentIndex); location = location.substring(0,fragmentIndex); } var index = location.indexOf('?'); if(index != -1) { //url 中已含有其他参数 location = location + '&csrftoken=' + token; } else { //url 中没有其他参? location = location + '?csrftoken=' + token; } if(fragment != null){ location += fragment; } element.setAttribute(attr, location); } } |
在客L html 中，主要是有两个地方需要加?tokenQ一个是表单 formQ另一个就是链?a。这D代码首先遍历所有的 formQ在 form 最后添加一隐藏字段Q把 csrftoken 攑օ其中。然后，代码遍历所有的链接标记 aQ在?href 属性中加入 csrftoken 参数。注意对?a.href 来说Q可能该属性已l有参数Q或者有锚标记。因此需要分情况讨论Q以不同的格式把 csrftoken 加入其中?/p>
如果你的|站使用 XMLHttpRequestQ那么还需要在 HTTP 头中自定?csrftoken 属性，利用 dojo.xhr l?XMLHttpRequest 加上自定义属性代码如下：
|
1 |
<strong><em>清单 4. ?HTTP 头中自定义属?lt;/em></strong> |
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 |
var plainXhr = dojo.xhr; // 重写 dojo.xhr Ҏ dojo.xhr = function(method,args,hasBody) { // 保 header 对象存在 args.headers = args.header || {}; tokenValue = '<%=request.getSession(false).getAttribute("csrftoken")%>'; var token = dojo.getObject("tokenValue"); // ?csrftoken 属性放到头? args.headers["csrftoken"] = (token) ? token : " "; return plainXhr(method,args,hasBody); }; |
q里改写?dojo.xhr 的方法，首先保 dojo.xhr 中存?HTTP _然后?args.headers 中添?csrftoken 字段Qƈ?token g session 里拿出放入字D中?/p>
CSRF 防MҎ选择之道
通过上文讨论可知Q目前业界应?CSRF d有一些克制方法，但是每种Ҏ都有利弊Q没有一U方法是完美的。如何选择合适的Ҏ非常重要。如果网站是一个现有系l，惌在最短时间内获得一定程度的 CSRF 的保护，那么验证 Referer 的方法是最方便的，要想增加安全性的话，可以选择不支持低版本览器，毕竟q前来_IE7+, FF3+ q类高版本浏览器?Referer D无法被篡攏V?/p>
如果pȝ必须支持 IE6Qƈ且仍焉要高安全性。那么就要?token 来进行验证，在大部分情况下，使用 XmlHttpRequest q不合适，token 只能以参数的形式放于h之中Q若你的pȝ不支持用戯己发布信息，那这U程度的防护已经_Q否则的话，你仍焉以防?token 被黑客窃取ƈ发动d。在q种情况下，你需要小心规划你|站提供的各U服务，从中间找出那些允许用戯己发布信息的部分Q把它们与其他服务分开Q用不同的 token q行保护Q这样可以有效抵御黑客对于你关键服务的攻击，把危害降到最低。毕竟，删除别h一个帖子比直接从别̎号中转走大笔存款严重E度要轻的多?/p>
如果是开发一个全新的pȝQ则抵M CSRF 的选择要大得多。笔者徏议对于重要的服务Q可以尽量?XMLHttpRequest 来访问，q样增加 token 要容易很多。另外尽量避免在 js 代码中用复杂逻辑来构造常规的同步h来访问需?CSRF 保护的资源，比如 window.location ?document.createElement(“a”) 之类Q这样也可以减少在附?token 时生的不必要的ȝ?/p>
最后，要记?CSRF 不是黑客唯一的攻LD，无论?CSRF 防范有多么严密，如果你系l有其他安全漏洞Q比如跨站域脚本d XSSQ那么黑客就可以l过你的安全防护Q展开包括 CSRF 在内的各U攻击，你的防线如同虚设?/p>
ȝ与展?/strong>
可见QCSRF 是一U危害非常大的攻击，又很难以防范。目前几U防御策略虽然可以很大程度上抵M CSRF 的攻击，但ƈ没有一U完的解决Ҏ。一些新的方案正在研I之中，比如对于每次h都用不同的动态口令，?Referer ?token Ҏl合hQ甚臛_试修?HTTP 规范Q但是这些新的方案尚不成熟，要正式投入用ƈ被业界广为接受还需时日。在q之前，我们只有充分重视 CSRFQ根据系l的实际情况选择最合适的{略Q这h能把 CSRF 的危害降到最低?/p>