此文是由本人在法国读研二时的一个课题报告翻译而来（保留版权），所以转载请标明原文出处：
http://blog.csdn.net/jiangsq12345/archive/2011/03/11/6239056.aspx
谢谢
关于网络安全
概要：
网络安全是指网络系统的硬件、软件及其系统中的数据受到保护，不因偶然的或者恶意的原因而遭受到破坏、更改、泄露，系统连续可靠正常地运行，保证网络服务不中断。
一般具备
4
个方面的特性：
保密性
：
信息不泄露给非授权用户
完整性
：信息在存储或传输过程中保持不被修改、不被破坏和丢失的特性
可用性
：被授权用户可以在一定的范围内操作
可控性
：对信息的传播及内容具有控制能力。
从某种角度来说，网络安全也属于系统安全的范畴之内，比分说：一个网站的漏洞可能直接被黑客利用从而达到攻击该服务器所在系统。我们先以
PostgreSQL,PHP
在本地搭建了一个网站（网站源代码由老师提供），这篇文章将讲述我们用当今主流攻击方式（
SQL
注入，
Xss
等）来找到的该网站漏洞，从来加深对网络安全的认识。
网站简介
该网站由
HTML
，
PHP5
，
PostgreSQL8.3
配合
Apache
搭建在
Ubuntu9.04
平台，变形的
LAMP
结构。
首先，该网站的主页（插图
1
）登入前有
4
个页面：
Home
，
Login
，
Contacts
，
Search
。合法用户登入后有其他操作：查看受到的留言，管理帐号等。
插图1
用工具查找所有可能存在漏洞的
URL
关于这类帮忙查找网站可能存在漏洞的工具网络上很多，比方说：
---
Websecurity
（
Windows
版本比较好用）
---
Paros Proxy
（
java
编写）
我们这里采用
Paros
Proxy
这个工具。
Paros
Proxy
是一个用
Java
编写的开源软件，它可以用来扫描检查一个网站的所有可能存在的漏洞，包括：
Cookie
盗取，
SQL
注入，
Xss
等。使用方法也很简单，只要启动该软件，然后讲浏览器的代理服务器设为
Paros
，之后用浏览器尽量多的点击检查网站的所有
URL
。
Paros
能记录这些
URL
，最后启动扫描并会讲扫描结果保存到一个
HTML
文件里（插图
2
）。
我们这个例子里，它给出来机会所有可能存在漏洞的
URL
，特别是
SQL
和
Xss
的。
根据这些信息，经过多次重复测试检查，我们找到了很多真实存在的漏洞，在后面逐一列出。
插图
2
SQL
插入
SQL
插入是指用户通过提交一些出乎网站设计者意料之外的数据（包含
SQL
命令），并让网站数据库服务器执行从而达到不正当目的的黑客技术。
我们这个例子中有个网页
address_book.php
存在这个漏洞，因为
PHP
代码中直接将
order
这个值代入到
SQL
命令中。
情景
1
：我们可以在后面添加其他
SQL
代码，比如我们想在网站数据库中创建一个新表
game
，我们可以这样更改
URL
并提交
情景
2
：因为我们有网站的源代码，我们知道数据库表格格式，比如说用户表格是
users.accou
nts(
name
character varying not null, pass character varying not null
)
，
所以我们可以这样攻击：
然后我们可以光明正大地以
toutou
，
123456
这个帐号登入网站了。
其实在很多时候这样是行不同的，为什么呢？
因为自从
PHP5
以来，它的有一个配置
magic_quotes_gpc
默认已经改为
On
（表示所有从客户端过来的特殊字符都会加个反斜杠
/
，也就说刚才的提交的数据会被
PHP
变成
(/'toutou/',/'123456/')
PostgreSQL
当然是不接受这样的命令并报错的咯），这个配置给这类带有字符串的攻击带来了很大难度，但还是存在解决方法的。
情景
3
：
现在我们的问题其实很简单，只要能避免用一些特殊字符就能避免
PHP
这个强悍配置。因此我们就自然想到
ASCii
代码代替这些特殊字符，所以现在的问题归结为
PostgreSQL
是否存在这样的转换函数，答案是肯定的（
PostgreSQL
是用来取代
Mysql
的，当然不能比它逊色拉）
chr()
就能做到，然后用
||
来链接几个字符成串，所以有没有第三个版本
然后也可以用
toutou
，
123456
这个帐号登入网站了
或者用
$$
代替单引号，所以这样也行
防治办法：
采用
PHP
的
pg_query_params
（）
，避免使用
pg_query
（）。因为前者将数据也参数的形式传人函数，即时该参数包含任何字符都被认为是字符串，而且该函数一次自执行一次
SQL
命令，也就是之后的黑客插入的代码永远不会被执行
========================================
Xss
攻击
Xss
简单点说就是指让其他用户的浏览器加载并执行你的
script
代码，从而达到某种目的。
这个网站也存在这一样一个漏洞，就是我们可以给该网站管理员发送一封消息（包含
script
代码），当该管理员打开它消息浏览页面时，它的浏览器会自动加载该
script
。
情景
1
：
发送一个消息给管理员
toto
，主题栏填写简单
script
代码
插图
3
管理员
toto
登入它消息页面时会加载这个
script
，弹出一个提示框插图
4
插图
3
插图
4
情景
2
：盗取
Cookie
，并登入
根据这个我们可以来盗取管理员的
Cookie
，并模拟它无须密码登入网站。
首先说一下
Cookie
是用于
HTTP
协议，客户端登入服务器时，服务器为了区别不同的用户，所有给每个用户一个唯一的身份代码
cookie
。客观端以后再登入该服务器时自动会在
HTTP
包请求中添加之前服务器给的身份代码（直到失效）。所有如果我们获取了管理员的有效
Cookie
，发送
HTTP
请求时添加上这个
Cookie
，服务器会认为是管理员本人登入，所以不需要再次输入密码。
该攻击分
3
个步骤：
1.
在自己的电脑搭建一个网络服务器，然后编写一个简单的
php
文件（
recupcookies.php
）来接受别人发送过来的
cookie
等信息并保存在本地
cinfos.html
这个文件中。
2
。我们这边准备工作已经
ok
，现在我们可以给管理员发送消息
还是在之前填写
script
的那栏里，填写
但是如我们之前所说，如果
php
的
magic_quotes_gpc
配置为
On
这样是行不通的，所以我们可以用
scrip
的转
ascii
为字符串的函数
String.fromCharCode
（）
来完成，于是变形为
函数内一大堆数字代表
的字符串。
到此为止，我们的所有准备工作已经完成，现在就等管理员打开它的消息页面。我们打开
cinfos.html
会有如下信息
插图
6
特别注意
session
那栏信息，是我们要的关键内容
插图
6
第
3
步，也即是最后一步，模拟
cookie
并登入
这里我们介绍
Firefox
的一款插件
web
developer
，
可以完成查看、更改或者自己添加
cookie
的功能。
用
firefox
打开该网站，然后用
Cookies
→
View
Cookie Information
,
然后更改
cookie
，只要将我们自己的
cookie
改为我们收到的
cookie
，我们这个例子里是
df36373d0716317a44a8462e74849815
，并确认。
插图
7
然后我们刷新一下该网站的页面，我们就会发现已经以管理员的身份成功登入了，然后我们可以做很多的事情。。。
插图
7
防治此类
Xss
办法：
其实很简单，正是所以邮箱服务器做的那样，将
<
和
>
这两个符号用
html
转义字符代替。在
php
服务器
蛮力破解密码
最后我们再讲一种攻击方法——蛮力破解密码
，不过操作起来比较困难。
我们用
python
编写了一个小程序，思路是遍历所有数字
+
字母等所有可能的组合来破解用户密码。插图
8
但是没有时间去完成，也没有找到一个有效的遍历密码算法，这是我们以后要做的。
插图
8
防治办法
防止此类攻击的方法很多，比较可行的就是如果一个
IP
，尝试
3
次密码输入都错误就屏蔽该
IP
一段时间，这样会增加此类攻击的难度（基本能避免这种攻击）
总结
由于老师给我们创造了一个很好锻炼的平台，亲身实践网站攻击（
SQL
注入，
Xss
），让我们对网站的安全有来更加深入的认识。但是由于时间有限，我们只研究了比较主流的攻击技术，其实还有很多技术存在我们并没有接触。
这个课题的目的是让我们如何来防止黑客攻击，对于防治办法有很多，我们所讲的只是比较通用的，相信存在更加好更有效的方法。
====================================
对
SQL
注入的防治，国内有很多网站都是通过过滤
用户提交的数据（比分说删除一些
SQL
敏感关键字
Create
，
insert, table
等），我很想说一下自己的看法
本人认为用过滤用户提交过来的数据来达到防止
SQL
注入并不是一个好办法，有百害而无一利，下面例举几点：
1.
一个完美的防止
SQL
注入的这类函数，我想是不存在的。因为
SQL
语法那么丰富很难预测所有黑客的注入方式。确实网上流行的注入方式就那么几条，但是谁也不能保证所有的黑客都只会这几招三脚猫功夫。而且每次数据库版本的更新迫使你一次次地更改这个过滤函数，重复同样的工作是计算机人员最厌倦的事情。
2.
现在退一万步讲，假如你拥有这个完美的过滤函数（相对意义上还是可能的），我想它的代码必定相当客观的。每次用户提交过来的数据就必须通过这个繁琐函数的检查替换，这必将严重降低网站服务器的效率
。而从用户来讲最讨厌的就是坐在浏览器前等待一个网页的慢慢打开，他们很难接受一个响应迟钝的网站。
3.
还是假设有这么个完美函数，那我相信过滤掉的用户信息也是相当可观的，比分说我想写博客时写个create单词都不肯，
这不是赤裸裸地侵犯用户权利嘛！
如果一个网站从
2
、
3
两点都“伤害”了一个用户，那十有八九将失去这个用户。而用户对于一个网站，就好比顾客对于商家，重要性不言而喻。
所以过滤并不是一个好的方法（不知道为什么国内这么多网站却这种方法，难到是因为操作比较简单？），凡是越大的网站就