CN104079528A

CN104079528A - 一种Web应用的安全防护方法及系统

Info

Publication number: CN104079528A
Application number: CN201310098783.7A
Authority: CN
Inventors: 刘胜飏; 王飞
Original assignee: Peking University Founder Group Co Ltd; Beijing Founder Electronics Co Ltd
Current assignee: Peking University Founder Group Co Ltd; Beijing Founder Electronics Co Ltd
Priority date: 2013-03-26
Filing date: 2013-03-26
Publication date: 2014-10-01

Abstract

本发明公开了一种Web应用的安全防护方法及系统，该方法及系统首先由管理员在Web客户端根据需要配置防护规则，形成防护规则文件，并将防护规则文件设置在服务器的安全防护模块中，设置为全局过滤器；在Web应用服务器接收用户的Web应用访问请求时，安全防护模块将Web应用访问请求的请求数据与配置的防护规则文件比较，查看请求数据与防护规则文件是否匹配，若是则拦截Web应用访问；若否则允许Web应用访问。本发明所述的方法及系统，可以根据需要防护所有Web应用，提高了Web访问的安全性。将Web应用访问的拦截动作从应用程序转移到了代理服务服务器中，避免了应用程序的重复开发或遗漏拦截，降低了成本。

Description

一种Web应用的安全防护方法及系统

技术领域

本发明涉及信息安全领域，具体涉及Web应用安全技术领域中一种部署在Web服务器上的Web应用的安全防护方法及系统。

背景技术

Web应用系统就是利用各种动态Web技术开发的，基于B/S(浏览器/服务器)模式的事务处理系统。当前，Web安全威胁愈演愈烈，对于用户而言,Web安全即是一场灾难。针对Web的攻击已经成为全球安全领域最大的挑战，主要原因有如下两点：

1.企业业务迅速更新，需要大量的Web应用快速上线。而由于资金、进度、意识等方面的影响，这些应用没有进行充分安全评估。

2.针对Web的攻击会隐藏在大量正常的业务行为中，而且使用各种变形伪装手段，会导致传统的防火墙和基于特征的入侵防御系统无法发现和阻止这种攻击。

全球知名的Web安全与数据库安全研究组织OWASP提供的报告显示，目前对Web业务系统威胁最严重的两种攻击方式是SQL注入攻击和跨站脚本(XSS)攻击。

针对Web安全。传统的做法一：防火墙，防火墙可以过滤掉非业务端口的数据，防止非Web服务出现的漏洞，目前市场上可选择的防火墙品牌也较多。但对于目前大量出现在应用层面上的SQL注入和XSS漏洞，防火墙无法过滤，因而无法保护Web服务器所面临的应用层威胁。传统做法二：在单个Web应用中加入防止攻击的代码，比如对用户的输入进行过滤等等。这样做的缺点是只能保护该应用自身，每个应用都需要单独做一套保护措施。另外可扩展性很差，如果要防止其他的攻击方式，还需要修改代码。重新编译，打补丁。对于生产系统，会带来很大的维护成本。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种Web应用的安全防护方法及系统，提高Web应用防护的安全性。

为实现上述目的，本发明采用的技术方案如下：

一种Web应用的安全防护方法，包括以下步骤：

（1）在Web客户端配置防护规则，形成防护规则文件；所述的配置防护规则是指创建需要拦截检查的url路径和创建url路径绑定规则，并将url路径与url路径绑定规则绑定；

（2）将所述的防护规则文件设置在安全防护模块中，并将安全防护模块设置为全局过滤器；所述的安全防护模块单独设置在代理服务器或者Web应用服务器的内存中；

（3）Web应用服务器接收用户的Web应用访问请求；

（4）安全防护模块将Web应用访问请求的请求数据与配置的防护规则比较，查看请求数据与防护规则文件是否匹配，若是则拦截Web应用访问；若否则允许Web应用访问。

一种Web应用的安全防护系统，包括：

防护规则设置模块：用于在Web客户端配置防护规则，形成防护规则文件；所述的配置防护规则是指创建需要拦截检查的url路径和创建url路径绑定规则，并将url路径与路径绑定规则绑定；

防护规则加载模块：用于将所述的防护规则文件加载到安全防护模块中，并将安全防护模块设置为全局过滤器；所述的安全防护模块单独设置在代理服务器或者Web应用服务器的内存中；

Web请求接收模块：用于接收用户的Web应用访问请求；

Web请求处理模块：用于安全防护模块将Web应用访问请求的请求数据与防护规则文件比较，查看请求数据与防护规则文件是否匹配，若是则拦截Web应用访问；若否则允许Web应用访问。

本发明的有益效果在于：本发明所述的方法将Web应用访问的拦截动作从应用程序转移到了Web服务器中，用于访问Web应用时，所有访问Web服务器（Web服务器为Web应用服务器）或者Web服务器所指向的应用服务器（Web服务器为代理服务器）的应用都会经过过滤，提高了web访问的安全性。此外，将Web应用访问的拦截动作从应用程序转移到了代理服务服务器中，避免了应用程序的重复开发或遗漏拦截，降低了成本。

附图说明

图1为本发明一种Web应用的安全防护系统的结构框图；

图2为本发明一种Web应用的安全防护方法的流程图。

具体实施方式

下面结合说明书附图与具体实施方式对本发明做进一步的详细说明。

本发明的主要思想：本发明是一种部署在Web服务器上的全局过滤器，系统管理员可以预先通过Web客户端程序配置自己需要的规则，规则配置好后启动防护模块所在的服务器。启动后，防护模块就可以正常工作了。其他用户访问配置要拦截的应用时，就会先通过防护模块进行过滤。防护模块根据预先配置好的规则与用户的请求以及响应做匹配。如果匹配成功，则认为是不正常的请求或攻击，执行配置好的动作处理，比如拒绝访问，重写请求数据等等。如果匹配不成功，则放行该请求或响应给真正的Web应用处理。有效地保护了Web应用，防止其被恶意攻击及信息泄露。

图1示出了本发明一种Web应用的安全防护系统的结构框图，该系统包括防护规则设置模块11、防护规则加载模块12、Web请求接收模块13和Web请求处理模块14，其中：

防护规则设置模块11用于在Web客户端配置防护规则，形成防护规则文件；所述的配置防护规则是指创建需要拦截检查的url路径和创建url路径绑定规则，并将url路径与路径绑定规则绑定；

防护规则加载模块12用于将所述的防护规则文件加载到安全防护模块中，并将安全防护模块设置为全局过滤器；所述的安全防护模块单独设置在代理服务器或者Web应用服务器的内存中；

Web请求接收模块13用于接收用户的Web应用访问请求；

Web请求处理模块14用于安全防护模块将Web应用访问请求的请求数据与防护规则文件比较，查看请求数据与防护规则文件是否匹配，若是则拦截Web应用访问；若否则允许Web应用访问。该模块包括用于查看Web应用访问请求的url路径是否进行了配置，若是则进入规则匹配单元，若否则允许Web应用访问的url配置查看单元，和用于将请求数据与规则进行比较，查看请求数据与规则是否匹配，如是则拦截Web应用访问，若否则允许Web应用访问的规则匹配单元。

图2示出了基于图1中安全防护系统的一种Web应用的安全防护方法的流程图，该方法主要包括以下步骤：

步骤S21：在Web客户端配置防护规则；

在Web客户端配置防护规则，形成防护规则文件；所述的配置防护规则是指创建需要拦截检查的url路径和创建url路径绑定规则，并将url路径与url路径绑定规则绑定。系统管理员可以预先通过Web客户端配置自己需要的url路径绑定规则，通过Web客户端程序进行配置，具体如下：

1、配置需要拦截检查的url路径，包括：

1）配置授权主机名hostname和文件路径节点filepathnode（可以配置多级路径），授权hostname一般为服务器名称或者IP地址。

举例：配置的需要拦截检查的url为：

http://192.168.1.1/myApp/test/test.asp

其中，IP地址为192.168.1.1，需要访问的文件路径为myApp/test/test.asp。

2）创建url路径绑定规则。url路径绑定规则包括规则名称（通过名称可以知道该规则可以拦截哪种攻击）、规则语法（可以定义是否匹配正则表达式，是否与某个值相等，等等）、动作处理（可以包括写日志、拒绝访问、重写请求、执行某个命令等等）。其中，动作处理可以定义为很多种，一般可以分为两大类，黑名单动作处理和白名单动作处理，黑名单动作处理包括拒绝访问、写日志、重写请求数据；白名单动作包括执行请求命令。

2、绑定规则

给预先创建的url路径的组成部分绑定定义好的url路径绑定规则

url路径可绑定规则的部分有：

Request:method;version;url;queryString;queryStrng parameter;body;body parameter;header;header parameter;

Response:response status;body;

在将url的组成部分与url路径绑定规则绑定时，可以绑定一个以上的规则，也可以绑定规则组，用户可以根据需要进行设置。上述可绑定的部分均是web领域公知的词汇，如Request是指……请求，即客服端发来的请求；Method是指……HTML<form>标签的属性，规定如何发送表单数据；Version是指……HTML标签，设置或获取管理当前文档的文档类型定义版本；response指响应，是服务器做出的响应；在此不再一一描述。上述列举的这些部分也仅是举例说明这些部分可以绑定规则，但不限于这些部分，用于可以根据需要选择更多可以绑定规则的部分。本实施方式中将url路径与url路径绑定规则绑定实际上指的是将url路径与路径绑定规则“匹配”的一个过程，匹配的方法可以是正则表达式等一些现有技术。

步骤S22：将防护规则文件设置在安全防护模块；

通过Web服务器的设置，将步骤S21中设置的防护规则文件设置在安全防护模块中，并将安全防护模块设置为全局过滤器；其中，安全防护模块单独设置在代理服务器或者Web应用服务器的内存中。也就是说安全防护模块可以单独部署在一台web服务器上，将该服务器作为代理服务器使用，也可以将安全防护模块与Web应用部署在同一台服务器上，即将安全防护模块部署在Web应用服务器上。工作时，启动安全防护模块所在的服务器后，会先加载步骤S21中配置好的防护规则文件，将文件加载到内存中。本发明的安全防护模块为代理服务器时，用户通过该代理服务器向Web应用服务器发起Web应用访问请求。

本发明中所述的安全防护模块，，其概念范围甚广，指一切可提供网络安全保护功能的系统或装置，如入侵检测系统、网络防火墙、网络防病毒系统等等，对本领域技术人员是说，安全防护模块是常用的技术手段。安全防护规则文件可设置在其它产品或系统的安全防护模块中，也可以单独部署，通过Web服务等方式提供安全防护服务，实际上也构成了一个安全防护模块，将安全防护规则文件设置在产品或系统的安全防护模块中，或者单独部署的方式对本领域技术人员来说也是常用的技术手段。

这样，通过Web服务器的设置，将安全防护模块部署为全局的过滤器，所有访问这台Web应用服务器上或者由该代理服务器指向的服务器上的应用都会先经过安全防护模块的过滤。本实施方式中优选的将安全防护模块部署在一台Web服务器上，单独部署的好处是可以有效地节省Web应用服务器的资源，减少压力。

步骤S23：Web应用服务器接收用户的Web应用访问请求；

步骤S24：将请求数据与配置的防护规则文件比较,根据比较结果处理Web应用访问。

Web客户端向Web应用服务器发送Web应用访问请求，Web服务器的安全防护模块拦截该访问请求，将Web应用访问请求的请求数据与配置的防护规则文件比较，查看请求数据与防护规则文件是否匹配，若是则拦截Web应用访问；若否则允许Web应用访问。所述的拦截Web应用访问是指执行黑名单动作，所述的允许Web应用访问是指执行白名单动作。

Web服务器将Web应用访问请求的请求数据与配置的防护规则文件比较的具体方式为：

1）查看Web应用访问请求的url路径是否进行了配置，若是则进入步骤2），若否则允许Web应用访问；访问Web应用的请求过来后，由安全防护模块拦截，然后将访问请求的url路径与步骤S21中配置的需要拦截检查的url路径进行比较，如果没有配置该url，则放过该请求到真正的应用；如果匹配上，则进行步骤2）；

2）将将请求数据与url路径绑定规则进行比较，查看请求数据与url路径绑定规则是否匹配，如是则拦截Web应用访问，若否则允许Web应用访问。在将请求数据与url路径绑定规则比较前，首先将Web应用访问请求进行解析，将请求数据转换为url路径绑定规则匹配需要的标准格式。做转换的目的只要是为了应对不同的Web server所产生的请求数据不一致的情况。即不同的Web server对规则匹配模块是透明的。请求数据转换主要包括url解码和解码后的拆分等过程，由于包含不安全字符、中文、保留字等原因，url通常会进行编码，url解码则是还原url的过程，url解码为现有技术，还原后的url将进一步被拆分为scheme(通讯协议)、host(主机)、port(端口号)、path(路径)、query(查询)、fragment(信息片段)等部分，对可能被攻击的部分绑定规则进行安全防护，该过程均现有技术。转换后，将转换后的用户请求数据与加载到内存的url路径绑定规则进行匹配。如果匹配不成功，则认为是正常的，放过该请求到真正的应用。如果匹配成功，则进行下一步的动作处理。动作处理可以定义为多种，主要分为两大类，白名单和黑名单。白名单的动作处理主要是Pass，也可以加Log。即匹配成功后直接放过请求，跳过后面的规则匹配。对于黑名单，一般定义为deny。即如果黑名单匹配成功，则拒绝访问，并打日志。还可以定义为rewrite，即过滤危险字符，改写用户的请求后再放到真正的应用。

本发明有两个主要优点：

一、一次部署，可以保护Web server上的所有Web应用，只需要在客户端Web程序中配置相应的url即可。

二、管理员可以配置要检查请求或响应哪些部分，也可以配置要拦截哪些请求。同时也可以自定义正则表达式或者检查方式，只要符合规则语法规范即可。方便灵活。

本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

下面结合具体实施例对本发明进行进一步的说明。

实施例

本实施例以包含用户输入参数的url防护为例，其主要步骤包括：

步骤1：配置防护规则；

例如，为防止在输入参数中包含可能产生危害的SQL命令，可以创建如下的防护规则文件QuerystringRule.json：

其中，json格式的防护规则文件是一种轻量级的数据交换格式文件，易于阅读和编写，当然在创建防护规则文件时也可以xml或数据库表等其它形式存储。

步骤2：将防护规则文件部署在安全防护模块。

将上一步中设置的防护规则文件部署在安全防护模块中，并将安全防护模块设置为全局过滤器，Web应用访问请求将首先被发送到安全防护模块中进行安全检查。

步骤3：将Web应用访问请求发送至安全防护模块。

例如，web应用服务器接收到一个包含用户输入参数的url访问请求：http://192.168.1.1/myApp/test/showdetail.asp?id=1;delete from users（该请求是一个包含SQL注入的非法请求，会删除数据库users表全部数据），该请求将首先被发送至安全防护模块进行检查。

步骤4：将请求数据与配置的防护规则比较,根据比较结果处理Web应用访问。

上述url请求经过解码、解析，可获取到QueryString为id=1;delete fromusers，将QueryString与防护规则文件进行比对，发现其中包含防护规则文件中的禁用文本“delete”和“;”，因此该访问请求是一个非法访问，将拦截该访问请求。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其同等技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种Web应用的安全防护方法，包括以下步骤：

（3）Web应用服务器接收用户的Web应用访问请求；

2.如权利要求1所述的一种Web应用的安全防护方法，其特征在于：步骤（1）中，所述的url路径绑定规则包括规则名称、规则语法和动作处理。

3.如权利要求2所述的一种Web应用的安全防护方法，其特征在于：所述的规则语法包括是否匹配正则表达式和是否与设定参数值相等；所述的动作处理包括黑名单动作处理和白名单动作处理两大类，黑名单动作处理包括拒绝访问、写日志、重写请求数据；白名单动作包括执行请求命令。

4.如权利要求1至3之一所述的一种Web应用的安全防护方法，其特征在于：步骤（1）中，将url路径与url路径绑定规则绑定是指将url路径的组成部分与url路径绑定规则绑定。

5.如权利要求4所述的一种Web应用的安全防护方法，其特征在于：步骤（2）中，所述安全防护模块单独设置在代理服务器时，用户通过代理服务器向Web应用服务器发起Web应用访问请求。

6.如权利要求4所述的一种Web应用的安全防护方法，其特征在于：步骤（4）中，安全防护模块将Web应用访问请求的请求数据与防护规则文件比较的具体方式为：

1）查看Web应用访问请求的url路径是否进行了配置，若是则进入步骤2），若否则允许Web应用访问；

2）将请求数据与url路径绑定规则进行比较，查看请求数据与url路径绑定规则是否匹配，若是则拦截Web应用访问，若否则允许Web应用访问。

7.如权利要求6所述的一种Web应用的安全防护方法，其特征在于：步骤2）中，将请求数据与url路径绑定规则进行比较前，首先解析Web应用访问请求，将请求数据转换为url路径绑定规则匹配需要的标准格式。

8.如权利要求7所述的一种Web应用的安全防护方法，其特征在于：步骤（4）中，所述的拦截Web应用访问是指执行黑名单动作，所述的允许Web应用访问是指执行白名单动作。

9.一种Web应用的安全防护系统，包括：

Web请求接收模块：用于接收用户的Web应用访问请求；

10.如权利要求9所述的一种Web应用的安全防护系统，其特征在于，所述的Web请求处理模块包括：

url配置查看单元：用于查看Web应用访问请求的url路径是否进行了配置，若是则进入规则匹配单元，若否则允许Web应用访问；

规则匹配单元：用于将请求数据与url路径绑定规则进行比较，查看请求数据与url路径绑定规则是否匹配，如是则拦截Web应用访问，若否则允许Web应用访问。