有遵循
安全代码进行开发，攻击者将通过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代替避开检测。
依赖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,establisheduricontent:".pl"pcre:"/(\%27)|(\’)|(\-\-)|(%23)|(#)/i"
classtype:Web-application-attacksid:9099rev: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查询, 示范提交如下输入:
3insert 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)|(=))[^\n]*((\%27)|(\’)|(\-\-)|(\%3B)|(:))/i
解释:
这个规则首先留意 = 号或它的hex值(%3D)，然后考虑零个或多个除换行符以外的任意字符，最后检测单引号，双重破折号或分号。
典
型的SQL注入会尝试围绕单引号的用途操作原来的查询，以便得到有用的价值。讨论这个攻击一般使用1’or’1’=’1字符串. 但是,
这个串的侦查很容易被逃避，譬如用1’or2>1 --.
然而唯一恒定的部分是最初的字符的值，跟随一单引号，再加’or’。随后的布尔逻辑可能在一定范围上变化，可以是普通样式也可能是非常复杂的。这些攻击可
以相当精确被侦测，通过以下的正则表达式。2.3章节讲解。
2.3 典型的 SQL 注入攻击的正则表达式
/\w*((\%27)|(\’))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
解释:
\w* - 零个或多个字符或者下划线。
(\%27)|\’ - 单引号或它的hex等值。
(\%6 F)|o|(\%4 F))((\%72)|r|-(\%52) －‘or’的大小写以及它的hex等值。
’union’SQL
查询在SQL注入各种数据库中攻击中同样是很常见的。如果前面的正则表达式仅仅检测单引号或则其他的SQL meta characters
，会造成很多的错误存在。你应该进一步修改查询，检测单引号和关键字‘union’。这同样可以进一步扩展其他的SQL关键字，像’select’,
’insert’, ’update’, ’delete’, 等等。
2.4 检测SQL注入，UNION查询关键字的正则表达式
/((\%27)|(\’))union/ix
(\%27)|(\’) - 单引号和它的hex等值
union - union关键字
可以同样为其他SQL查询定制表达式，如 >select, insert, update, delete, drop, 等等.
如
果，到这个阶段，攻击者已经发现web应用程序存在SQL注入漏洞，他将尝试利用它。如果他认识到后端服务器式MS SQL
server，他一般会尝试运行一些危险的储存和扩展储存过程。这些过程一般以‘sp’或‘xp’字母开头。典型的，他可能尝试运行
‘xp_cmdshell’扩展储存过程（通过SQL Server执行Windows
命令）。SQL服务器的SA权限有执行这些命令的权限。同样他们可以通过xp_regread, xp_regwrite等储存过程修改注册表。
2.5 检测MS SQL Server SQL注入攻击的正则表达式
/exec(\s|\+)+(s|x)p\w+/ix
解释:
exec - 请求执行储存或扩展储存过程的关键字
(\s|\+)+ - 一个或多个的空白或它们的http等值编码
(s|x) p- ‘sp’或‘xp’字母用来辨认储存或扩展储存过程
\w+ - 一个或多个字符或下划线来匹配过程的名称
3. 跨站脚本(CSS)的正则表达式
当
发动CSS攻击或检测一个网站漏洞的时候, 攻击者可能首先使简单的HTML标签如(粗体),(斜体)或(下划线)，或者他可能尝试简单的
script标签如alert("OK").
因为大多数出版物和网络传播的检测网站是否有css漏洞都拿这个作为例子。这些尝试都可以很简单的被检测出来。
然而，高明点的攻击者可能用它的hex值替换整个字符串。这样标签会以%3C%73%63%72%69%70%74%3E出 现。
另一方面，攻击者可能使用web代理服务器像Achilles会自动转换一些特殊字符如换成%3E.这样攻击发生时，URL
中通常以hex等值代替角括号。
下列正则表达式将检测任何文本中包含的html的。它将捉住试图使用、、或。这正则表达式应该忽略大小写。我们需要同时检测角括号和它的hex等值(% 3C|
3.1 一般 CSS 攻击的正则表达式
/((\%3C)|)/ix
解释:
((\%3C)|) －检查>或它的hex等值
Snort 规则:
alert
tcp $EXTERNAL_NET any ->$HTTP_SERVERS $HTTP_PORTS (msg:"NII
Cross-site scripting attempt"flow:to_server,established
pcre:"/((\%3C)|)/i"classtype:Web-application-attacksid:9000rev:5)
跨站脚本同样可以使用技术。现行默认的snort规则可以被轻易避开。
3.2章节提供了防止这种技术的方法。
3.2 "
/((\%3C)|)/I
解释:
(\%3 C)|) ->或它的hex等值
3.3 CSS 攻击的极端的正则表达式
/((\%3C)|)/I
解释:
这个规则简单寻找。由于你的web服务器和web应用程序的构架，这个规则可能产生一些错误。但它能保证捉住任何CCS或者类似CSS的攻击。
一个不错避开过滤的CSS方法请参考Bugtraq投稿的
http://www.securityfocus.com/archive/1/272...rchive/1/272037.
但是请注意最后一种极端的规则将能检测这所有的攻击。
总结:
在
这篇文章中，我们提出了不同种类的正则表达式规则来检测SQL注入和跨站脚本攻击。有些规则简单而极端，一个潜在的攻击都将提高警惕。但这些极端的规则可
能导致一些主动的错误。考虑到这点，我们修改了这些简单的规则，利用了另外的样式，他们可以检查的更准确些。在这些网络应用成的攻击检测中，我们推荐将这
些作为调试你IDS或日志分析方法的起点。再经过几次修改后，在你对正常网交易部分的非恶意应答进行评估以后，你应该可以准备的检测那些攻击了。
对于他们的攻击，主要是通过使用正则表达式来做输入检测：
检测SQL meta-characters的正则表达式 ：/(\%27)|(’)|(--)|(\%23)|(#)/ix
解释:我 们首先检查单引号等值的hex，单引号本身或者双重扩折号。
修正检测SQL meta-characters的正则表达式： /((\%3D)|(=))[^ ]*((\%27)|(’)|(--)|(\%3B)|(:))/i
解释: 这个规则首先留意 = 号或它的hex值(%3D)，然后考虑零个或多个除换行符以外的任意字符，最后检测单引号，双重破折号或分号。
典型的 SQL 注入攻击的正则表达式： /w*((\%27)|(’))((\%6F)|o|(\%4F))((\%72)|r|(\%52))/ix
解释:
w* - 零个或多个字符或者下划线。
(\%27)|’ - 单引号或它的hex等值。
(\%6 F)|o|(\%4 F))((\%72)|r|-(\%52) －‘or’的大小写以及它的hex等值
检测SQL注入，UNION查询关键字的正则表达式: /((\%27)|(’))union/ix
(\%27)|(’) - 单引号和它的hex等值
union - union关键字
可以同样为其他SQL查询定制表达式，如 >select, insert, update, delete, drop, 等等.
检测MS SQL Server SQL注入攻击的正则表达式: /exec(s|+)+(s|x)pw+/ix
exec - 请求执行储存或扩展储存过程的关键字
(s|+)+ - 一个或多个的空白或它们的http等值编码
(s|x) p- ‘sp’或‘xp’字母用来辨认储存或扩展储存过程
w+ - 一个或多个字符或下划线来匹配过程的名称
CSS的检测也主要是正则表达式：
一般 CSS 攻击的正则表达式: /((\%3C)|<)((\%2F)|/)*[a-z0-9\%]+((\%3E)|>)/ix
解释:
((\%3C)|<) －检查<和它hex等值
((\%2F)|/)*－结束标签/或它的 hex等值
[a-z0-9\%]+ －检查标签里的字母或它hex等值
((\%3E)|>) －检查>或它的hex等值
"<img src" CSS 攻击正则表达式: /((\%3C)|<)((\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47))[^ ]+((\%3E)|>)/I
解释:
(\%3 C)|<) -<或它的hex等值
(\%69)|i|(\%49))((\%6D)|m|(\%4D))((\%67)|g|(\%47) -’img’字母或它的大小写hex等值的变化组合
[^ ]+ -除了换行符以外的任何跟随<img的字符
(\%3E)|>) ->或它的hex等值
CSS 攻击的极端的正则表达式 ： /((\%3C)|<)[^ ]+((\%3E)|>)/I
解释:
这个规则简单寻找<+除换行符外的任何字符+>。由于你的web服务器和web应用程序的构架，这个规则可能产生一些错误。但它能保证捉住任何CCS或者类似CSS的攻击。
随着前端技术的发展,安全问题已经从服务器悄然来到了每一个用户的的面前，盗取用户数据, 制造恶意的可以自我复制的蠕虫代码,让病毒在用户间传播,使服务器当掉. 更有甚者可能会在用户不知觉得情况下,让用户成为攻击者,这绝对不是骇人听闻。富客户端的应用越来越广，前端的安全问题也随之增多,今天就简单介绍下一些常见的攻击方式和预防攻击办法。常见攻击
XSS (Cross Site Script) ，跨站脚本攻击。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入的恶意html代码会被执行，从而达到恶意用户的特殊目的。XSS属于被动式的攻击，因为其被动且不好利用，所以许多人常呼略其危害性。但是随着前端技术的不断进步富客户端的应用越来越多，这方面的问题越来越受关注。举个简单例子 ： 假如你现在是sns站点上一个用户，发布信息的功能存在漏洞可以执行js 你在 此刻输入一个 恶意脚本，那么当前所有看到你新信息的人的浏览器都会执行这个脚本弹出提示框 （很爽吧 弹出广告 ：）），如果你做一些更为激进行为呢 后果难以想象。
CSRF(Cross Site Request Forgery)，跨站点伪造请求。顾名思义就是 通过伪造连接请求在用户不知情的情况下，让用户以自己的身份来完成攻击者需要达到的一些目的。csrf 的攻击不同于xss csrf 需要被攻击者的主动行为触发。这样听来似乎是有“被钓鱼”的嫌疑哈哈。
多窗口浏览器这这方面似乎是有助纣为虐的嫌疑，因为打开的新窗口是具有当前所有会话的，如果是单浏览器窗口类似ie6 就不会存在这样的问题，因为每个窗口都是一个独立的进程。举个简单例子 ： 你正在玩白社会， 看到有人发了一个连接，你点击过去，然后这个连接里面伪造了一个送礼物的表单，这仅仅是一个简单的例子，问题可见一般。
cookie劫持，通过获取页面的权限，在页面中写一个简单的到恶意站点的请求，并携带用户的cookie 获取cookie后通过cookie 就可以直以被盗用户的身份登录站点。这就是cookie 劫持。举个简单例子： 某人写了一篇很有意思的日志，然后分享给大家，很多人都点击查看并且分享了该日志，一切似乎都很正常，然而写日志的人却另有用心，在日志中偷偷隐藏了一个对站外的请求,那么所有看过这片日志的人都会在不知情的情况下把自己的cookie 发送给了 某人，那么他可以通过任意一个人的cookie 来登录这个人的账户。
我们该怎么做？
大致可以分为两类 1 一般用户 2网站开发人员。
首先我们来说说做为一个一般的web产品使用者，很多时候我们是被动的，是在不知情的情况下被利用的。那么我们可以：
1 对于安全级别较高的web应用访问 需要打开一个独立浏览器窗口。
2 对于陌生人发布的链接最好也是复制然后在新开的窗口中打开，当然最好的办法就是无视 – -。
对于开发人员来说我们得从相对详细的一些角度来分析：
对于xss 攻击 特点是攻击者的代码必须能获取用户浏览器端的执行权限，那么代码是从哪里来的呢，想要杜绝此类攻击出现 其实可以在入口 和出口 进行严格的过滤，这样的双保险应当说99% 的类似问题就被我们解决掉了，另外的1% 是那些蹩脚的浏览器带来的后遗症，相信在未来这种问题会越来越少的。
这里我对xss漏洞的形式作了一些整理
恶意代码值被作为某一标签的内容显示 （如果输入的是html 则html会被解析）例如你输入用户名 更新后用户名会显示到页面中的某一个标签内 如果你输入的是
popper.w＜script src="hack.js" type="text/javajscript"＞＜/script＞
那么如果不做过滤直接显示到页面， 会引进一个第三方的js 代码并且会执行。
策略：在不需要html输入的地方对html 标签 及一些特殊字符( ” ＜ ＞ &等等 )做过滤，将其转化为不被浏览器解释执行的字符
恶意代码被作为某一标签的属性显示（通过用 “ 将属性截断来开辟新的属性 或恶意方法） 这种情况往往是是开发人员为了实现功能可能会在某些dom标签上记录一些用户输入的信息例如你输入的用户名 会在页面中的标签中以 title 的形式出现 这时候 如果 你输入的是精心设计的内容 那么 看看 这个
＜a title="popper.w" onclick="alert(1)"＞popper.w" onclick="alert(1)＜/a＞
这里我实际上输入的内容是“popper.w” onclick=”alert(1)”，当然你可以在上边写更多的内容。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
恶意代码被作为html代码本身显示 (常见的html编辑器) 这种情况存在的问题最多，不再这里举例子了。
策略：最好对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。
恶意代码被作为一段json字符串显示 （通过 变量截断 创造新的 恶意的js 变量 甚至是可执行的代码） 这个问题的关键是用户输入的信息可能会成为页面中js 代码的一部分。
策略：对属性中可能存在截断的一些字符进行过滤 属性本身存在的 单引号和双引号都需要进行转码。
对于crsf 和cookie 劫持
特点 隐蔽性比较高 有些时候是先利用xss 漏洞 然后再做 欺骗的
策略
通过 referer、token 或者 验证码 来检测用户提交。
尽量不要在页面的链接中暴漏任何与用户唯一号（用户id）有关的信息。
对于用户修改 删除 提交的操作最好都使用post 操作 。
避免全站通用的cookie 严格的设置cookie的域。
ok 就写到这里~
上边讲的都是一些比较常见的安全问题，主要是从js hack 方面来讲的，随着前端技术的不断发展进步，更多的安全问题可能会展现在我们面，对于开发者来说大多数的问题是可以在开发阶段避免的，所以可怕的不是hack 可怕的是我们对自己的产品安全的松懈
