http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-scripting-attacks

在这两年中，安全专家应该对网络应用层的攻击更加重视。因为无论你有多强壮的防 火墙规则设置或者非常勤于补漏的修补机制，如果你的网络应用程序开发者没有遵循安全代码进行开发，攻击者将通过80端口进入你的系统。广泛被使用的两个主 要攻击技术是SQL注入[ref1]和CSS[ref2]攻击。SQL注入是指：通过互联网的输入区域，插入SQL meta-characters（特殊字符 代表一些数据）和指令，操纵执行后端的SQL查询的技术。这些攻击主要针对其他组织的WEB服务器。CSS攻击通过在URL里插入script标签，然后 诱导信任它们的用户点击它们，确保恶意Javascript代码在受害人的机器上运行。这些攻击利用了用户和服务器之间的信任关系，事实上服务器没有对输 入、输出进行检测，从而未拒绝javascript代码。

这篇文章讨论SQL注入和CSS攻击漏洞的检测技术。网上已经有很多关于这两种基于WEB攻击的讨论，比如如何实施攻击，他们的影响，怎样更好的编 制和设计程序防止这些攻击。 然而, 对如何检测这些攻击并没有足够的讨论。我们采用流行的开源的IDS Snort[ref 3],组建根据检测这些攻击的规则的正则表达式。附带，Snort默认规则设定包含检测CSS的方法，但是这些容易被避开检测。比如大多通过hex进制编 码,如%3C%73%63%72%69%70% 74%3E代替<script>避开检测。

依赖level of paranoia组织的能力，我们已经编写了多种检测相同攻击的规则。如果你希望检测各种可能的SQL注入攻击，那么你需要简单的留意任何现行的SQL meta-characters，如单引号，分号和双重破折号。同样的一个极端检测CSS攻击的方法，只要简单地提防HTML标记的角括号。但这样会检测 出很多错误。为了避免这些，这些规则需要修改使它检测更精确些, 当仍然不能避免错误。

在Snort规则中使用pcre(Perl Compatible Regular Expressions)[ref4]关键字，每个规则可以带或不带其他规则动作。这些规则也可以被公用软件如grep(文档搜索工具)使用，来审阅网络 服务器日志。 但是,需要警惕的是，用户的输入只有当以GET提交请求时，WEB服务器才会记录日记,如果是以POST提交的请求在日记中是不会记录的。

2. SQL注入的正则表示式

当 你为SQL注入攻击选择正则表示式的时候，重点要记住攻击者可以通过提交表单进行SQL注入，也可以通过Cookie区域。你的输入检测逻辑应该考虑用户 组织的各类型输入(比如表单或Cookie信息)。并且如果你发现许多警告来自一个规则，请留意单引号或者是分号，也许些字符是你的Web应用程序创造的 合法的在CookieS中的输入。因此, 您需要根据你的特殊的WEB应用程序评估每个规则。

依照前面提到，一个琐细的检测SQL射入攻击的正则表达式要留意SQL特殊的meta-characters 譬如单引号(’)双重扩则号(--),为了查出这些字符和他们hex等值数, 以下正则表达式适用:

2.1 检测SQL meta-characters的正则表达式

/(\%27)|(’)|(--)|(\%23)|(#)/ix

解释:

我 们首先检查单引号等值的hex，单引号本身或者双重扩折号。这些是MS SQL Server或Oracle的字符, 表示后边的为评论, 随后的都将被忽略。 另外，如果你使用MySQL,你需要留意 ’#’和它等值的hex的出现。注意我们不需要检查双重破折号等值的hex, 因为这不是HTML meta-character, 浏览器不会进行编码。 并且, 如果攻击者设法手工修改双重破折号为它的hex值%2D(使用代理像Achilles[ref 5]), SQL注入将失败。
加入上述正则表达式的新的Snort规则如下:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27)|(’)|(--)|(%23)|(#)/i"; classtype:Web-application-attack; sid:9099; rev:5;)

在本篇讨论中, uricontent关键字的值为".pl ", 因为在我们的测试环境里, CGI 程序是用Perl写的。uricontent关键字的值取决于您的特殊应用, 这个值也许是".php ", 或" .asp ", 或" .jsp ", 等。 从这点考虑, 我们不显示对应的Snort 规则, 但是我们会给出创造这些规则的正则表达式。 通过这些正则表达式你可以很简单的创造很多的Snort规则.在前面的正则表达式里, 我们检测双重破折号是因为：即便没有单引号的存在那里也可能是SQL射入点[ref 6]。 例如, SQL查询条目只包含数值，如下:

select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number

这种情况，攻击者可以执行额外的SQL查询, 示范提交如下输入:

3; insert values into some_other_table

最后, pcre的修饰符’ i’ 和’ x ’ 是用于分别匹配大小写和忽略空白处的。 上面的规则也可以另外扩展来检查分号的存在。然而，分号很可以是正常HTTP应答的一部分。为了减少这种错误，也是为了任何正常的单引号和双重扩折号的出 现，上面的规则应该被修改成先检测＝号的存。用户输入会响应一个GET或POST请求，一般输入提交如下：

username=some_user_supplied_value&password=some_user_supplied_value

因此, SQL 注入尝试将导致用户的输入出现在a = 号或它等效的hex值之后。

2.2 修正检测SQL meta-characters的正则表达式

/((\%3D)|(=))[^ ]*((\%27)|(’)|(--)|(\%3B)|(:))/i

解释:

这个规则首先留意 = 号或它的hex值(%3D)，然后考虑零个或多个除换行符以外的任意字符，最后检测单引号，双重破折号或分号。

典型的SQL注入会尝试围绕单引号的用途操作原来的查询，以便得到有用的价值。讨论这个攻击一般使用1’or’1’=’1字符串. 但是, 这个串的侦查很容易被逃避，譬如用1’or2>1 --. 然而唯一恒定的部分是最初的字符的值，跟随一单引号，再加’or’。随后的布尔逻辑可能在一定范围上变化，可以是普通样式也可能是非常复杂的。这些攻击可 以相当精确被侦测，通过以下的正则表达式。2.3章节讲解。

2.3 典型的 SQL 注入攻击的正则表达式

/**
 * 用于的使 Browser 不缓存页面的过滤器
 */
public class ForceNoCacheFilter implements Filter {

 public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException
 {
  ((HttpServletResponse) response).setHeader("Cache-Control","no-cache");
  ((HttpServletResponse) response).setHeader("Pragma","no-cache");
  ((HttpServletResponse) response).setDateHeader ("Expires", -1);
  filterChain.doFilter(request, response);
 }

 public void destroy()
 {
 }

    public void init(FilterConfig filterConfig) throws ServletException
 {
 }
}

二、检测用户是否登陆的过滤器

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import java.util.List;
import java.util.ArrayList;
import java.util.StringTokenizer;
import java.io.IOException;

/**
 * 用于检测用户是否登陆的过滤器，如果未登录，则重定向到指的登录页面<p>
 * 配置参数<p>
 * checkSessionKey 需检查的在 Session 中保存的关键字<br/>
 * redirectURL 如果用户未登录，则重定向到指定的页面，URL不包括 ContextPath<br/>
 * notCheckURLList 不做检查的URL列表，以分号分开，并且 URL 中不包括 ContextPath<br/>
 */
public class CheckLoginFilter
 implements Filter
{
    protected FilterConfig filterConfig = null;
    private String redirectURL = null;
    private List notCheckURLList = new ArrayList();
    private String sessionKey = null;

 public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException
 {
  HttpServletRequest request = (HttpServletRequest) servletRequest;
  HttpServletResponse response = (HttpServletResponse) servletResponse;

   HttpSession session = request.getSession();
  if(sessionKey == null)
  {
   filterChain.doFilter(request, response);
   return;
  }
  if((!checkRequestURIIntNotFilterList(request)) && session.getAttribute(sessionKey) == null)
  {
   response.sendRedirect(request.getContextPath() + redirectURL);
   return;
  }
  filterChain.doFilter(servletRequest, servletResponse);
 }

 public void destroy()
 {
  notCheckURLList.clear();
 }

 private boolean checkRequestURIIntNotFilterList(HttpServletRequest request)
 {
  String uri = request.getServletPath() + (request.getPathInfo() == null ? "" : request.getPathInfo());
  return notCheckURLList.contains(uri);
 }

 public void init(FilterConfig filterConfig) throws ServletException
 {
  this.filterConfig = filterConfig;
  redirectURL = filterConfig.getInitParameter("redirectURL");
  sessionKey = filterConfig.getInitParameter("checkSessionKey");

  String notCheckURLListStr = filterConfig.getInitParameter("notCheckURLList");

  if(notCheckURLListStr != null)
  {
   StringTokenizer st = new StringTokenizer(notCheckURLListStr, ";");
   notCheckURLList.clear();
   while(st.hasMoreTokens())
   {
    notCheckURLList.add(st.nextToken());
   }
  }
 }
}

三、字符编码的过滤器

import javax.servlet.*;
import java.io.IOException;

/**
 * 用于设置 HTTP 请求字符编码的过滤器，通过过滤器参数encoding指明使用何种字符编码,用于处理Html Form请求参数的中文问题
 */
public class CharacterEncodingFilter
 implements Filter
{
 protected FilterConfig filterConfig = null;
 protected String encoding = "";

 public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException
 {
        if(encoding != null)
         servletRequest.setCharacterEncoding(encoding);
        filterChain.doFilter(servletRequest, servletResponse);
 }

 public void destroy()
 {
  filterConfig = null;
  encoding = null;
 }

    public void init(FilterConfig filterConfig) throws ServletException
 {
         this.filterConfig = filterConfig;
        this.encoding = filterConfig.getInitParameter("encoding");

 }
}

四、资源保护过滤器

package catalog.view.util;
import javax.servlet.Filter;
import javax.servlet.FilterConfig;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import java.io.IOException;
import java.util.Iterator;
import java.util.Set;
import java.util.HashSet;
//
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
/**
* This Filter class handle the security of the application.
*

* It should be configured inside the web.xml.
*
* @author Derek Y. Shen
*/
public class SecurityFilter implements Filter {
//the login page uri
private static final String LOGIN_PAGE_URI = "login.jsf";
//the logger object
private Log logger = LogFactory.getLog(this.getClass());
//a set of restricted resources
private Set restrictedResources;
/**
* Initializes the Filter.
*/
public void init(FilterConfig filterConfig) throws ServletException {
this.restrictedResources = new HashSet();
this.restrictedResources.add("/createProduct.jsf");
this.restrictedResources.add("/editProduct.jsf");
this.restrictedResources.add("/productList.jsf");
}
/**
* Standard doFilter object.
*/
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException {
this.logger.debug("doFilter");
String contextPath = ((HttpServletRequest)req).getContextPath();
String requestUri = ((HttpServletRequest)req).getRequestURI();
this.logger.debug("contextPath = " + contextPath);
this.logger.debug("requestUri = " + requestUri);
if (this.contains(requestUri, contextPath) && !this.authorize((HttpServletRequest)req)) {
this.logger.debug("authorization failed");
((HttpServletRequest)req).getRequestDispatcher(LOGIN_PAGE_URI).forward(req, res);
}
else {
this.logger.debug("authorization succeeded");
chain.doFilter(req, res);
}
}
public void destroy() {}
private boolean contains(String value, String contextPath) {
Iterator ite = this.restrictedResources.iterator();
while (ite.hasNext()) {
String restrictedResource = (String)ite.next();
if ((contextPath + restrictedResource).equalsIgnoreCase(value)) {
return true;
}
}
return false;
}
private boolean authorize(HttpServletRequest req) {
//处理用户登录
/*	UserBean user = (UserBean)req.getSession().getAttribute(BeanNames.USER_BEAN);
if (user != null && user.getLoggedIn()) {
//user logged in
return true;
}
else {
return false;
}*/
}
}

       1、当用户进行的是Refresh/Reload/Back/Forward操作、以及先Back再Submit操作时，仅仅是reloading先前的结果页。

       2、当用户重复提交同一个任务操作时,后台服务接收并处理第一次提交的任务，后面提交不起作用（不转向也不提示）。

       3、该功能具有公用性。

基本形成思路：

       1、在basic filter中实现公用性

                if(true){//问题1：如何确定是否为重复提交

                         ...

                         chain.doFilter(request,response);

                }else{

                         //问题2：如何实现不转向、不提示也不显示空白页

                }

       2、网上资料概括

                a、提交表单后按钮变灰/隐藏提交按钮

                b、在js里设置全局变量，提交后修改该变量的值，依据变量的值判断是否重复提交

                         var flag=true;

                         function checkForm(){

                                   if (flag==false){

                                            return;

                                   }

                                   flag=false;

                                   document.form1.submit();

                         }

                c、struts （webwork没有找到这个资料）

                         //验证事务控制令牌,<html:form >会自动根据session中标识生成一个隐含input代表令牌，防止两次提交

                         在action中：

                                //<input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="6aa35341f25184fd996c4c918255c3ae">

                                if (!isTokenValid(request))

                                    errors.add(ActionErrors.GLOBAL_ERROR,

                                               new ActionError("error.transaction.token"));

                                resetToken(request); //删除session中的令牌

                         action有这样的一个方法生成令牌华

                            protected String generateToken(HttpServletRequest request) {

                                HttpSession session = request.getSession();

                                try {

                                    byte id[] = session.getId().getBytes();

                                    byte now[] =

                                        new Long(System.currentTimeMillis()).toString().getBytes();

                                    MessageDigest md = MessageDigest.getInstance("MD5");

                                    md.update(id);

                                    md.update(now);

                                    return (toHex(md.digest()));

                                } catch (IllegalStateException e) {

                                    return (null);

                                } catch (NoSuchAlgorithmException e) {

                                    return (null);

                                }

                            }          

                d、用户使用浏览器时，可以经常使用向后的按钮，因此就有可能重复提交一个他们已经提交过的form，这样就会带来一个重复事务处理的问题。同样，一个用户也可能在接收到一个确认的页面之前按下停止的按钮，接着再次提交同一个form。对于这些情况，我们都想跟踪并且禁止这些重复的提交，我们可以使用一个控制servlet来提供一个控制点，以解决这个问题。

                　　同步记号（Synchronizer (or Dvu) Token）

这个策略是为了解决重复的form提交问题。一个同步的记号被设置在一个用户的Session中，并且包含在返回到客户的每一个form中。当form被提交时，form中的同步标记就和Session中的同步标记作对比。在form首次提交的时候，这两个标记应该是一样的。如果标记不一样，那么该form就会禁止提交，一个错误就会返回给用户。在用户提交一个form时，如果按下浏览器中的后退按钮并尝试重新提交同一个form时，标记就会出现不匹配的现象。

另一方面，如果两个标记值匹配，那么我们就可以确信整个流程是正确的。在这种情况下，Session中的标记值就会被修改为一个新的值，同时允许提交该form。                                 　　你也可以使用这个策略来控制对某些页面的直接访问，就好象上面资源保护中描述的一样。例如，假设一个用户将某个应用的页面A收藏到收藏夹中，而页面A只允许通过页面B和C访问。当用户直接通过收藏夹来访问页面A，这时页面的访问顺序就是不正确的，这样同步标记将处在一个不同步的状态，或者它根本就不存在。不论怎样，访问都被禁止了。                 e、做一个hidden框，名字自己定，提交后得到这个值放入session，提交前判断session是否为空   解决方案：        1、后台公共类中实现前台的Form中自动生成两个hidden文本功能，一个是作page是否重复提交判断，并由系统自动附上关键值（如struts采用的方案）；另一个作为button是否重复提交判断（struts中好像没有）。由后台公共类实现界面两个hidden text自动生成的好处在于公用性。        2、在basic filter中根据两个hidden text值判断是否为重复提交。        3、javascript中作一个公共方法，实现功能：如果需要判断是否重复提交，就给第二个hidden text附上关键值，并使该功能不可用。 . 个人感想：我相信未来该功能一定会被服务器集成，而不再由开发人员进行编码.

----------------------------------------示例代码----------------------------------------------------

第一，对于不支持POST的，可以简单的使用如下代码
if ("POST".equals(request.getMethod())) ...{
  // 正常进行
}else...{
  // 异常请求
  out.print("异常访问");
  return;
}
如果是servlet, 可以将doGet方法直接返回，不进行处理就行了
public void doGet(HttpServletRequest request, HttpServletResponse response) ...{
  return;
}
public void doPost(HttpServletRequest request, HttpServletResponse response) ...{
  // 正常进行操作
}
还可以采用特定的标志来区分，比如
<form><input type="hidden" name="action" value="insert"/></form>
程序里这样判断
if ("POST".equals(request.getMethod()) && ("insert".equals(request.getParameter("action")))) ...{
  // 正常进行
}else...{
  // 异常请求
  out.print("异常访问");
  return;
}
第二，判断提交的来源referer,代码如下
if ("POST".equals(request.getMethod())) ...{
  String referer = request.getHeader("referer");
  if (referer == null || !referer.startsWith("http://"+request.getServerName())) ...{
    // 非法来源
    return;
  }
  // 正常进行
}else...{
  // 异常请求
  out.print("异常访问");
  return;
}
第三 防止重复提交的hashCode
在表单显示页面
  //生成一个formhash,算法可以自己定，不随便重复就可以了
  String formhash = MD5.encode(Long.toString(new Date().getTime()));
  //读取当前session里面的hashCode集合，此处使用了Set，方便判断。
  Set<String> formhashSession = (Set<String>) session.getAttribute("formhashSession");
  if (formhashSession == null) ...{
    formhashSession = new HashSet<String>();
  }
  // 检测重复问题
  while (formhashSession.contains(formhash)) ...{
    formhash = MD5.encode(Long.toString(new Date().getTime()));
  }
  // 保存到session里面
  formhashSession.add(formhash);
  // 保存
  session.setAttribute("formhashSession", formhashSession);
表单里面增加如下字段
<input type="hidden" name="formhash" id="formhash" value="<%=formhash%>" />
在表单提交页面进行如下处理
    // 拿到表单的formhash
    String formhash = upload.getParameter("formhash");
    // 拿到session里面的集合
    Set<String> formhashSession = (Set<String>) session.getAttribute("formhashSession");
    // 如果没有，则是重复提交，或者非法提交
    if (formhashSession == null || !formhashSession.contains(formhash)) ...{
      out.println("请不要重复提交！");
      return;
    }
    // 下面进行其它的操作
    //
    // 最后,如果操作成功,从session里面把这个formhash 删掉！
    // 以免用户少填写了某个字段，造成表单无法再次提交
    formhashSession.remove(formhash);
    session.setAttribute("formhashSession", formhashSession);

目前没有证据表明有Gmail用户的密码被盗。Google公司方面表示，在受到攻击数小时后，公司就激活了Gmail新的加密层，而且加强了数据 中心的安全性，并进一步加强了其网上服务与用户计算机之间通信连接的安全。但是，有安全分析人员指出，攻击者在攻入了内部密码系统之后，有可能在Gaia 系统和Google全球数据中心中安装木马，只不过在Google的安全专家获知受攻击之后，这变得非常困难。另外，攻击者在获取了系统的源代码并了解了 系统运作机理之后，也有可能（虽然可能性不大）发现Google还不知道的安全漏洞，这种隐患很令安全专家头痛。

文中还解释了此次Google所受攻击的详细过程：

1. 攻击者首先通过微软MSN给一个Google中国的员工A发去一条即时消息。

2. 这个员工在不知情的情况下点击了其中的网址，并访问了“已污染的”网站，使攻击者获得了访问A使用的计算机的权限。

3. 攻击者由此访问了Google公司的内部目录系统（名为Moma），其中保存着所有Google员工的工作情况，包括具体员工的信息。

4. 在查找到了位于Google美国总部的Gaia软件开发者的名字之后，他们继而首先尝试访问开发者的工作电脑。

5. 然后使用了一连串复杂的技术获取了Gaia系统源代码库的访问权限。

6. 接下来，他们把偷到的软件传输到云计算服务提供商Rackspace的计算机上，此后再传到哪里，就不再为人所知。

文中说，Gaia系统目前仍然在使用，现在的正式名称被称为Single Sign-On。

本周一Google的高管拒绝对此进行评论，说其中暴露的安全问题早已经解决。

有安全专家表示，新的攻击细节很可能增加人们对云计算安全的担心。由于海量的信息现在被相对集中存放在一些计算机系统中，单点被攻破就可能带来灾难 性的损失。

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://127.0.0.1/index.php

这个表示同时处理1000个请求并运行1000次index.php文件.
#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312
This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        Apache/2.0.54
//平台apache 版本2.0.54
Server Hostname:        127.0.0.1
//服务器主机名
Server Port:            80
//服务器端口

Document Path:          /index.html.zh-cn.gb2312
//测试的页面文档
Document Length:        1018 bytes
//文档大小

Concurrency Level:      1000
//并发数
Time taken for tests:   8.188731 seconds
//整个测试持续的时间
Complete requests:      1000
//完成的请求数量
Failed requests:        0
//失败的请求数量
Write errors:           0

Total transferred:      1361581 bytes
//整个场景中的网络传输量
HTML transferred:       1055666 bytes
//整个场景中的HTML内容传输量
Requests per second:    122.12 [#/sec] (mean)
//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8188.731 [ms] (mean)
//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate:          162.30 [Kbytes/sec] received
//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
              min mean[+/-sd] median   max
Connect:        4 646 1078.7     89    3291
Processing:   165 992 493.1    938    4712
Waiting:      118 934 480.6    882    4554
Total:        813 1638 1338.9   1093    7785
//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50%   1093
66%   1247
75%   1373
80%   1493
90%   4061
95%   4398
98%   5608
99%   7368
100%   7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒

      由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数