CN102082780B - 安全验证的方法和装置 - Google Patents

Abstract

本发明提供一种用于在网络应用中对用户的输入进行安全验证的方法，包括：向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的安全规则子集，以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证；基于该保护装置的安全规则，对用户的输入进行验证；响应于检测到违规的用户的输入并且所违反的安全规则未被提供到该预验证组件，将该用户确定为第一类用户；以及响应于检测到违规的用户的输入并且所违反的安全规则已被提供到该预验证组件，将该用户确定为第二类用户。

Description

安全验证的方法和装置

技术领域

本发明涉及网络安全的解决方案，特别地，本发明涉及在网络应用中对用户的输入进行安全验证的方法和装置。

背景技术

现今，网络应用(Web application)中存在的安全漏洞的数目正在快速增加。网络应用可能遭受的攻击类型包括跨站脚本(XSS)攻击、SQL注入式攻击、LDAP注入式攻击、命令接入式攻击、PHP注入式攻击等等。统计数据表明，有75％的攻击是针对应用层的，而90％的站点对于网络应用攻击是脆弱的。

在Web应用安全的常规解决方案中，一方面，在客户端侧使用Web应用查看工具检查代码；另一方面，在Web应用服务器侧使用Web应用防火墙来过滤并且阻止恶意输入。由于恶意用户有可能绕过客户端侧的Web应用查看工具直接向Web应用服务器注入恶意代码或者脚本，因此在Web应用服务器侧进一步对用户的输入进行验证是非常必要的。

Web应用防火墙是一种Web应用服务器侧的透明的保护装置，其被配置为至少具有以下功能性：用于基于预先定义的安全规则验证用户的输入；对于违反安全规则的用户输入采取适当安全保护动作。当检测到违反预定义的安全规则的用户输入时，诸如Web应用防火墙的保护装置会根据预先设定的规则采取对应的行动，例如，阻止IP、拒绝请求、生成日志，或者重新写入有效负载等。

通过对在线Web应用的观察，可以发现在服务器侧由保护装置检测到的违反安全规则的情况可以归因为以下两种情况：

1.无辜用户误输入某些违反安全规则的值；

2.恶意用户通过使用某些工具绕过客户端侧的用户输入验证机

制向Web应用服务器注入恶意输入值以进行攻击。

然而现有的对用户输入的验证方案并不能有效的识别无辜用户和恶意用户。保护装置难以有针对性的采取适当的安全保护动作。例如，如果对输入错误的无辜用户执行阻止其IP或者拒绝请求等动作，则会严重影响用户对于该Web应用的使用体验；如果无论恶意用户还是无辜用户造成违规时都拒绝请求并以用户友好的方式提供安全提示，或者重写用户的请求(Rewrite Request)进而提交给服务器端应用，则会增大安全验证系统的性能的消耗。

因此，需要提供一种网络应用的安全验证方案能够有效识别无辜用户和恶意用户。

发明内容

为了克服现有技术中的缺陷，本发明提出一种用于在网络应用中对用户的输入进行安全验证的方法。该方法包括：向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的安全规则子集，以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证；基于该保护装置的安全规则，对用户的输入进行验证；响应于检测到违规的用户的输入并且所违反的安全规则未被提供到该预验证组件，将该用户确定为第一类用户；以及响应于检测到违规的用户的输入并且所违反的安全规则已被提供到该预验证组件，将该用户确定为第二类用户。

本发明还提出一种用于在网络应用中对用户的输入进行安全验证的装置。该装置包括：用于向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的安全规则子集、以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证的装置；用于基于该保护装置的安全规则、对用户的输入进行验证的装置；用于响应于检测到违规的用户的输入并且所违反的安全规则未被提供到该预验证组件、将该用户确定为第一类用户的装置；以及用于响应于检测到违规的用户的输入并且所违反的安全规则已被提供到该预验证组件、将该用户确定为第二类用户的装置。

本发明还涉及包括该在网络应用中对用户的输入进行安全验证的装置的安全验证系统。

根据本发明的技术方案，能够有效地区分“第二类用户”和“第一类用户”。可以针对第二类用户和第一类用户配置不同的应对方案，由此提高验证过程的针对性。根据本发明的一个实施例，既能够尽量保证“第一类用户”对Web应用的使用体验，又可以最大限度地避免无谓的系统性能消耗。此外，根据本发明的技术方案还有利于减轻服务器侧保护装置的工作负荷，从而提高整个安全验证系统的性能。

附图说明

通过以下结合附图的说明，并且随着对本发明的更全面了解，本发明的其他目的和效果将变得更加清楚和易于理解，其中：

图1示意性示出根据本发明一个实施方式能够实现其中的系统结构；

图2示出了根据本发明一个实施方式的对用户的输入进行安全验证的方法流程图；

图3示出了根据本发明一个实施方式的服务器侧保护装置和客户端侧预验证组件的工作流程图；

图4示意性示出根据本发明一个实施方式的安全验证系统的模块间交互图。

在所有的上述附图中，相同的标号表示具有相同、相似或相应的特征或功能。

具体实施方式

图1示意性示出根据本发明一个实施方式能够实现其中的系统结构。其中标号11表示客户端侧的客户端浏览器，用于向Web应用服务器发送用户的HTTP请求并且接收相应的响应；标号12表示网络，经由该网络Web应用服务器能够响应用户通过客户端浏览器经由该网络发送的请求；标号10表示Web应用服务器侧的保护装置，用于在服务器侧验证用户请求中的输入值，为Web应用服务器提供安全保护；标号13表示Web应用服务器。

如图1所示，用户通过位于客户端侧的客户端浏览器11经由网络12向Web应用服务器13发送带有输入值的请求。需要对用户输入值进行验证，以便确保Web应用的安全。通常的用户在使用Web应用时不会在客户端侧键入逻辑代码(例如，JavaScript逻辑)等恶意值，然而潜在的恶意用户为了实现其攻击服务器或者窃取其它用户私人信息等的目的会向Web应用服务器13注入恶意逻辑代码，该恶意代码如JavaScript被服务器发送到其他客户端浏览器时，会窃取客户端的敏感信息。虽然客户端侧可以配置有Web应用查看工具(未示出)来对用户输入值进行检测，但是恶意用户可以使用某些工具绕过Web应用查看工具，例如以攻击脚本，注入工具如WebScrab的方式直接向Web应用服务器13注入恶意值。因此，服务器侧的诸如应用防火墙的保护装置10需要配置有预先定义的安全规则，并基于该预先定义的安全规则验证用户的输入值。当保护装置10检测到违反安全规则的用户输入值时，则需要对该用户采取适当安全保护措施，以消除潜在的安全隐患。表1示出了保护装置10可能采用的示例性的安全规则。

表1

应用特定的规则	ALLOWRULE″URI/testresult.html；name^[a-zA-Z0-9\s.\-]*$；age^[0-9]+$″；″ID＝050000，SEVERITY＝2，type＝MALFORMED，action＝deny″
		否定规则	DENYRULE“ALL/((\％3C)|＜)((\％2F)|\/)*[a-z0-9\％]+((\％3E)|＞)/ix″″ID＝090001，SEVERITY＝1，type＝XSS，action＝deny″

模式别名	正则表达式
		安全文本(SafeText)	^[a-zA-Z0-9\s.\-]*$
电子邮件(eMail)	^[\w-]+(？：\.[\w-]+)*(？：[\w-]+\.)+[a-zA-Z]{2，7}$

整数(Integer)	(-|\)？[0-9]+
		XSS注入式(XSS Inject)	/((\％3C)|＜)((\％2F)|\/)*[a-z0-9\％]+((\％3E)|＞)/ix
SQL注入式(SQL Inject)	/\w*((\％27)|(\’))((\％6F)|o|(\％4F))((\％72)|r|(\％52))/ix

在表1所示的安全规则的示例中包括应用特定的规则和否定规则。应用特定的规则规定了由具体应用确定的各种输入域的安全规则信息，例如表示“姓名”、“年龄”等域中允许的用户输入值的信息。例如，“姓名”所允许的输入值是由“安全文本”的正则表达式所定义的；“年龄”所允许的输入值是由“整数”的正则表达式所定义的。应用特定的规则还规定了违反该规则的攻击类型为“MALFORMED”以及所应采取的安全保护动作为“拒绝”。否定规则规定了用户输入的否定值，即否定所有符合“XSS(跨站脚本攻击)”的正则表达式的所有用户输入值。否定规则还规定了违反该安全规则的攻击类型为“XSS(跨站脚本攻击)”以及所应采取的安全保护动作为“拒绝”。

虽然在表1中示出了保护装置10所配置的安全规则的示例，但是保护装置10中的安全规则还可以包括其它形式。实际上，根据下文所述的内容本领域技术人员可以理解，安全规则的具体形式和内容并不对本发明构成限制。

在为Web应用提供的安全验证方案中，应该避免保护装置10仅简单根据预先定义的安全策略，对误输入违反安全策略的值的无辜用户执行阻止其IP、拒绝请求等严重影响该用户对于Web应用的使用体验的安全保护动作；并且还应该避免保护装置10对注入恶意代码的无辜用户执行发出用户友好的安全提示、甚至重新为其写入有效载荷等的增加系统性能的消耗的安全保护动作。在根据本发明的安全验证方案中，保护装置10能够有效地区分违反安全规则的用户的类别，由此使得保护装置10能够有针对性的对违规采取适当的安全保护动作，即保证第一类用户(倾向于被判定为无辜用户)的用户体验，又不必为第二类用户(倾向于被判定为恶意用户)浪费宝贵的系统性能。

注意到，第一类用户倾向于根据系统所提供的安全提示修正违规输入，最终使得用户输入值符合安全规则；然而，第二类用户是以向Web应用服务器13注入恶意值为目的的，其输入不会由于验证过程中的用户友好的交互最终符合安全规则。因此，本发明提出保护装置10向客户端浏览器11部署预验证组件，并且使得预验证组件基于保护装置10提供的某些安全规则在客户端侧对用户输入进行预验证。保护装置10根据预定义的安全规则对该用户输入进行验证，并且根据客户端侧的预验证以及其自身验证，确定该用户是第一类用户还是第二类用户，由此选择所要执行的安全保护动作。

图2示出了根据本发明一个实施方式的对用户的输入进行安全验证的方法流程图。

在步骤S200中，该方法开始。

在步骤S210中，向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的子集，以便由预验证组件基于所提供的安全规则子集在客户端侧执行对用户输入值的安全验证。

客户端的预验证组件可以由保护装置部署到客户端，也可以由客户端的插件通过网络从保护装置获取。例如，该预验证组件可以是独立Javascript组件。在一种实现方式中，保护装置将Javascript预验证组件插入到应用响应页面，通过客户端浏览器运行该预验证组件。

保护装置提供给客户端侧预验证组件的安全规则优选地是保护装置安全规则的真子集。可以向预验证组件提供表明安全规则的安全策略文件。在安全策略文件中可以简单包括：在客户端侧需要由预验证组件监控的URI、域名称、模式别名(例如，电子邮件、URL、安全文本、XSS等)，只要在客户端侧预验证组件中定义的模式正则表达式与在服务器端保护装置中定义的模式正则表达式相兼容即可。

在步骤S220中，当检测到违规用户输入值时，确定所违反的安全规则是否被提供到客户端侧的预验证组件。

如果在步骤S220中确定所违反的安全规则已经被提供到客户端侧的预验证组件，这意味着在服务器侧的保护装置检测到本应在客户端侧通过预验证模块解决的安全问题，该违规的用户通过攻击工具等手段绕过客户端侧的预验证机制，直接将违规恶意值注入Web应用服务器。由此，在步骤S230中将该违规的用户确定为“第二类用户”。其中该第二类用户倾向于被判定为恶意用户。

另一方面，如果在步骤S220中确定所违反的安全规则未被提供到客户端侧的预验证组件，则在步骤S240将该违规的用户确定为“第一类用户”。其中该第一类用户倾向于被判定为无辜用户。

优选地，在步骤S250中，异步地对提供给预验证组件的安全规则的子集进行动态更新。“异步地”执行该更新步骤意味着该更新步骤相对于整个验证过程来说是相对独立的执行的。例如，在一种实现中可以利用AJAX(Asynchronous JavaScript and XML)技术将该更新过程以后台运行的方式实现。该更新步骤可以周期性或者不定期的进行，其中由保护装置以一定策略从总的安全规则集合中筛选出将要提供给预验证组件的安全规则子集。保护装置可以根据安全验证日志的统计数据为各条安全规则按违规率进行排序，筛选出违规率高的安全规则提供给客户端侧的预验证组件。例如，还可以注意到，第二类用户可能会分析客户端侧预验证组件对输入值的响应(例如，各种安全提示等)来获取预验证组件中安全规则的信息，因此筛选对于预验证组件的安全规则子集时应该对某些特定规则有所保留。在一个优选的实施例中，所筛选的安全规则子集可以满足从以下组中选择的一项或多项：

1.选择违规率高的安全规则；

2.未包括安全规则集合中所有否定规则；

3.不包括高风险的安全规则，即一旦违规严重威胁系统安全性的规则。

通过动态更新客户端侧预验证组件的安全规则子集，增加了预验证机制可能覆盖的安全规则的范围，并且使得第二类用户难以通过尝试输入的方式获取有关安全规则的信息，因为更新动作以及更新内容完全由服务器方的保护装置决定，由此增加了预验证的准确性和系统的安全性。

在步骤S260中，该方法结束。

由于根据本发明的技术方案能够有效地区分用户的类别，因此可以将保护装置配置为针对确定的“第一类用户”和“第二类用户”执行不同的安全保护动作。例如，对于倾向于判定为“恶意用户”的“第二类用户”可以执行强制阻止其一切后续输入请求的安全保护动作，如阻止IP动作；对于倾向于被判定为“无辜用户”的“第一类用户”执行有利于保持该用户良好体验的安全保护动作，例如，拒绝请求并发出用户友好的安全提示和/或重新为其写入有效载荷等动作。

接下来，通过一个具体示例示出服务器侧和客户端侧各组件的工作流程及其交互，从而更加具体的描述根据本发明的技术方案。

图3示出了根据本发明一个实施方式的服务器侧保护装置和客户端侧预验证组件的工作流程图。

如图3所示，在步骤S301中，在保护装置10中建立预定义的安全规则的集合。安全规则的集合可以包括应用特定的规则以及否定规则。应该理解，该步骤与验证用户输入的过程是异步执行的，通常在部署保护装置10时就执行该步骤。

在步骤S302中，保护装置10重写应用响应页面，以便将独立Javascript预验证组件插入到应用响应页面。根据本发明的一个实现，Javascript预验证组件可以由表2中的代码实现：

表2由保护装置插入的Javascript预验证组件的代码示例

var element＝document.createElement(′script′)；element.setAttribute(′src′，′http://aspis.crl.abc.com/js/WAF_monitor.js′)；document.body.appendChild(element)；

在步骤S303中，在客户端浏览器11中运行该Javascript预验证组件。

该Javascript预验证组件为页面中的各个用户输入域添加属性改变事件(onPropertyChange event)的监控器，以便通过监视用户输入域的属性改变事件，激活对用户输入的预验证过程。该Javascript预验证组件还提供获取来自保护装置10的安全策略文件的装置，其中该安全策略文件表示保护装置10的安全规则的一个规则子集。

表3添加onPropertyChange事件的监控器的代码示例

var inputs＝document.getElementsByTagName(″input″)；for(var i＝0；i＜inputs.length；i++){if(inputs[i].type＝＝″text″)inputs[i].attachEvent(″onPropertyChange″，validation)；}

在步骤S304中，保护装置10向客户端浏览器11中的Javascript预验证组件发送或更新安全策略文件。该安全策略文件中所表示的安全规则子集是根据保护装置10检测的违规日志的统计数据，从保护装置10的总的安全规则集合中筛选的。该安全策略文件可以包括具有高违规率的输入域以及其对应模式的列表。

在步骤S305中，在客户端浏览器11中，Javascript预验证组件获取来自服务器侧保护装置10的安全策略文件。

在步骤S306中，在客户端浏览器11中，Javascript预验证组件响应于输入域属性改变事件，基于安全策略文件中的安全规则对用户输入域进行验证。在一个实现中，执行预验证的功能可以通过表4中所示代码实现。

表4基于从保护装置获得的策略文件执行预验证的代码示例

function validaion(){

var event＝window.event.srcElement；//安全策略文件可以定义了需要被验证的输入域，以及其使用哪种模式//安全策略文件可以从服务器侧的保护装置周期性地或者不定期地获得//可以使用例如AJAX(Asynchronous JavaSc ript and XML)等创建交互式网页应用的网页开发技术实现if(违反安全策略文件){document.getElementById(″errorMsg″).innerText＝″Error Info is Here″；}else{document.getElementById(″errorMsg″).innerText＝″″；}}

在检测到用户输入值违规时，向用户提供友好的提示，例如给出正确输入值的示例、指出当前输入值的问题等，以便用户能够根据提示正确完成对该输入域的输入。

在步骤S307中，客户端浏览器11将用户的HTTP请求发送给服务器侧的保护装置10。需要说明的是，由于Javascript预验证组件基于安全策略文件可能仅针对部分输入域或针对部分安全规则进行验证，因此并不是所有的用户输入值均经过Javascript预验证组件的预验证。也就是说，客户端浏览器11发送到保护装置10的用户HTTP请求即可能包括经过预验证的用户输入值，也可能包括未经预验证的用户输入值。应该理解，经过预验证的用户输入值符合安全规则，而未经过预验证的用户输入值有可能违反安全规则。

因此，在步骤S308中，在服务器侧的保护装置10基于预先定义的安全策略集合对HTTP请求中的所有用户输入值进行验证。

在步骤S309中，判断当保护装置10检测到违规时，所违反的安全规则是否已经被更新到客户端侧的Javascript预验证组件。

当保护装置10检测到违规，并且所违反的安全规则未被更新到客户端侧的Javascript预验证组件时，则在步骤S311中将对应的用户确定为“第一类用户”。其中该第二类用户倾向于被判定为恶意用户。

在步骤S312中，可以对该确定的“第一类用户”执行有利于保持该用户良好体验的安全保护动作，例如，重新构建用户的请求(Rewrite Reqeust)并发送到应用服务器应用中。其中该第一类用户倾向于被判定为无辜用户。

当保护装置10检测到违规，并且所违反的安全规则已经被更新到客户端侧的Javascript预验证组件时，则在步骤S313中将对应的用户确定为“第二类用户”。这是因为，该用户显然通过工具绕过客户端浏览器中的预验证机制，直接向应用服务器注入违反安全规则的恶意值。

在步骤S314中，可以对该确定的“第二类用户”执行强制阻止其一切后续请求的安全保护动作，例如阻止IP等动作。

本领域技术人员可以理解，对于不同的Web应用对于所确定的“第二类用户”或“第一类用户”所执行的相应安全保护动作可能不同。本领域的技术人员可以取决于应用的具体需求设定不同等级或特征的安全保护动作，并分配给所确定的“第二类用户”或“第一类用户”。

需要说明的是，虽然图3的示例通过Javascript预验证组件作为示例说明了本发明一种具体实施方式，应该理解，其它任何能够与Web应用兼容代码语言都能够用于实现在预验证组件，例如VBscript。而且，本领域技术人员可以任何已知方式，将该预验证组件部署到客户端。进一步的实现方式例如还可以包括在客户端侧提供特定的插件，从而主动获取预验证组件。因此，预验证组件的具体实现方式并不对本发明构成任何限制。

图4示意性示出根据本发明一个实施方式的安全验证系统的功能框图。

如图4所示，客户端浏览器11向Web应用服务器13发送HTTP请求，并从Web应用服务器13获得相应的响应。服务器侧的保护装置10基于预定义的安全规则集合对来自用户的请求进行输入验证，以确保Web应用服务器13的安全性。

保护装置10包括：可选的部署装置101，用于向客户端浏览器部署预验证组件；更新装置102，用于向客户端侧的预验证组件提供或者更新安全规则的子集；验证装置103，用于基于预先定义的安全规则集合对来自用户的请求进行输入验证；以及确定装置104，用于确定违规用户的类别，即倾向于被判定为无辜用户的“第一类用户”还是倾向于被判定为恶意用户的“第二类用户”。

在保护装置10中，可选地，由部署装置101例如通过重写应用响应页面，将独立Javascript组件插入到应用响应页面，在客户端浏览器11中部署预验证组件110。更新装置102向客户端浏览器11中的预验证组件110周期性地或者不定期地发送或更新安全策略文件，其中该安全策略文件中所表示的安全规则子集是根据保护装置10检测的违规日志的统计数据，从保护装置10的总的安全规则集合中筛选的。

预验证组件110在客户端浏览器11中运行，获取来自服务器侧保护装置10的安全策略文件，并基于安全策略文件中的安全规则对用户输入域进行验证，以确保用户输入不违反当前的安全规则子集。客户端浏览器11向Web应用服务器13侧发送用户的HTTP请求。

保护装置10的验证装置103基于预先定义的安全策略集合对来自用户的HTTP请求中所有用户输入值进行验证。当检测到违规时，确定装置104判断所违反的安全规则是否已经被更新到客户端浏览器11中的预验证组件110。如果所违反的安全规则还未被更新到客户端浏览器11中的预验证组件110，则确定装置104将该用户确定为“第一类用户”。如果所违反的安全规则已经被更新到客户端浏览器的预验证组件110，则确定装置104将该用户确定为“第二类用户”。保护装置可以被配置为针对确定的第一类用户和第二类用户执行不同的安全保护动作。例如，针对所确定的第一类用户执行有利于保持该用户良好体验的安全保护动作，如，重写用户的请求(Rewrite Request)等动作；针对所确定的第二类用户执行强制阻止其一切后续请求的安全保护动作，如阻止IP等动作。

根据本发明的安全验证方案，由Web应用服务器侧的保护装置向客户端侧部署预验证组件，并且为该预验证组件提供执行预验证的安全规则，优选地，动态更新该执行预验证的安全准则。由此保护装置在检测到违规的用户输入值时，通过确定该违反的规定是否已经在客户端侧的预验证组件进行了验证，就可以确定该用户是否为“第二类用户”，即该用户通过某种非法手段绕过客户端侧的预验证机制，直接向Web应用服务器发送恶意逻辑代码。可见，根据本发明的技术方案，能够有效地区分“第二类用户”和“第一类用户”，由此使得可以将保护装置配置为对于不同的用户采取不同的应对方案，即执行不同的安全保护动作。根据本发明的一个实施例，能够尽量保证“第一类用户”对Web应用的使用体验，又可以最大限度地避免无谓的系统性能消耗。此外，在客户端侧设置预验证机制，可以将部分验证过程分布到客户端侧执行，有利于减轻服务器侧保护装置的工作负荷，从而提高了整个验证系统的性能。

通过以上对具体实施例的描述，本领域技术人员可以理解，上述方法、装置以及相应系统可以使用计算机可执行指令和/或包含在处理器控制代码中来实现，例如在诸如磁盘、CD或DVD-ROM的载体介质、诸如只读存储器(固件)的可编程的存储器或者诸如光学或电子信号载体的数据载体上提供了这样的代码。本发明实施方式中的装置、单元可以由诸如超大规模集成电路或门阵列、诸如逻辑芯片、晶体管等的半导体、或者诸如现场可编程门阵列、可编程逻辑设备等的可编程硬件设备的硬件电路实现，也可以用由各种类型的处理器执行的软件实现，也可以由上述硬件电路和软件的结合实现。

提供本发明的说明书的目的是为了说明和描述，而不是用来穷举或将本发明限制为所公开的形式。对本领域的普通技术人员而言，许多修改和变更都是显而易见的。

因此，选择并描述实施方式是为了更好地解释本发明的原理及其实际应用，并使本领域普通技术人员明白，在不脱离本发明实质的前提下，所有修改和变更均落入由权利要求书所限定的本发明的保护范围之内。

Claims (14)

1.一种用于在网络应用中对用户的输入进行安全验证的方法，包括：

向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的安全规则子集，以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证；

基于该保护装置的安全规则，在所述服务器侧对用户的输入进行验证；

响应于检测到违规的用户的输入并且所违反的安全规则未被提供到该预验证组件，将该用户确定为第一类用户；以及

响应于检测到违规的用户的输入并且所违反的安全规则已被提供到该预验证组件，将该用户确定为第二类用户。

2.根据权利要求1所述的方法，还包括：

异步地对提供给该预验证组件的安全规则子集进行动态更新，

其中在向该预验证组件提供服务器侧保护装置的安全规则的安全规则子集的步骤中和异步地对提供给该预验证组件的安全规则子集进行动态更新的步骤中以一定策略从该保护装置的安全规则集合中筛选出所述安全规则子集。

3.根据权利要求1所述的方法，其中该预验证组件是能够在客户端浏览器中运行的独立Javascript组件。

4.根据权利要求1所述的方法，还包括：

针对确定的第一类用户和第二类用户执行不同的安全保护动作。

5.根据权利要求4所述的方法，其中针对确定的第一类用户和第二类用户执行不同的安全保护动作的步骤包括：

针对第二类用户执行强制阻止其一切后续请求的安全保护动作；以及

针对第一类用户执行有利于保持其良好体验的安全保护动作。

6.根据权利要求2所述的方法，其中所述策略包括从以下组中选择的一项或多项：

选择违规率高的安全规则；

未包括该安全规则集合中所有否定规则；

不包括该安全规则集合中高风险的安全规则。

7.根据权利要求3所述的方法，其中：

该预验证组件响应于输入域属性改变事件，基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证。

8.一种用于在网络应用中对用户的输入进行安全验证的装置，包括：

用于向部署在客户端的预验证组件提供服务器侧保护装置的安全规则的安全规则子集、以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证的装置；

用于基于该保护装置的安全规则、在所述服务器侧对用户的输入进行验证的装置；

用于响应于检测到违规的用户的输入并且所违反的安全规则未被提供到该预验证组件、将该用户确定为第一类用户的装置；以及

用于响应于检测到违规的用户的输入并且所违反的安全规则已被提供到该预验证组件、将该用户确定为第二类用户的装置。

9.根据权利要求8所述的装置，还包括：

用于异步地对提供给该预验证组件的安全规则子集进行动态更新的装置，

其中用于向该预验证组件提供服务器侧保护装置的安全规则的安全规则子集、以便由该预验证组件基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证的装置和用于异步地对提供给该预验证组件的安全规则子集进行动态更新的装置以一定策略从该保护装置的安全规则集合中筛选出所述安全规则子集。

10.根据权利要求8所述的装置，其中该预验证组件是能够在客户端浏览器中运行的独立Javascript组件。

11.根据权利要求8所述的装置，还包括：

用于针对确定的第一类用户和第二类用户执行不同的安全保护动作的装置。

12.根据权利要求11所述的装置，其中用于针对确定的第一类用户和第二类用户执行不同的安全保护动作的装置包括：

用于针对第二类用户执行强制阻止其一切后续请求的安全保护动作的装置；以及

用于针对第一类用户执行有利于保持其良好体验的安全保护动作的装置。

13.根据权利要求9所述的装置，其中所述策略包括从以下组中选择的一项或多项：

选择违规率高的安全规则；

未包括该安全规则集合中所有否定规则；

不包括该安全规则集合中高风险的安全规则。

14.根据权利要求10所述的装置，其中：

该预验证组件响应于输入域属性改变事件，基于所提供的该安全规则子集在客户端侧执行对用户输入的安全验证。

Images