得知互动
标题: 黑客攻防技术宝典——Web实战篇 [打印本页]
作者: DeGe 时间: 2013-6-8 15:37
标题: 黑客攻防技术宝典——Web实战篇
Web应用程序安全的关键问题因素：
1. 不成熟的安全意识
2. 独立开发
3. 欺骗性的简化
4. 迅速发展的威胁形式
5. 资源与时间限制
6. 技术上强其所难
Web应用程序使用三层相关联的安全机制处理用户访问：
1. 身份验证
2. 会话管理
3. 访问控制
处理用户输入：
1. 输入的多样性
2. 输入处理方法：
a) 拒绝已知的不良输入
b) 接受已知的正常输入
c) 净化
d) 安全数据处理
e) 语法检查
3. 边界确认步骤：
a) 应用程序受到用户的登录信息
b) 应用程序执行一个SQL查询检验用户证书
c) 如果用户成功登录，应用程序再将用户资料中的某些数据传送给SOAP服务，经一步获得用户账户的有关信息
d) 应用程序在用户的浏览器中显示用户的帐户信息
4. 多步确认与规范化
处理攻击者：
1. 处理错误
2. 维护审计日志
3. 向管理员发出警报
4. 应对攻击
HTTP
1. HTTP请求：每个HTTP请求的第一行都由三个以空格间隔的项目组成
三个项目：
1) 一个说明HTTP方法的动词（最常用的是GET）
2) 被请求的URL
3) 使用的HTTP版本
2. HTTP响应：每个HTTP响应的第一行都由三个以空格间隔的项目组成
三个项目：
1) 使用的HTTP版本
2) 表示请求结果的数字状态码
3) 一段文本形式的“原因短语”，进一步说明响应状态
3. HTTP方法：
GET——获取资源
POST——执行操作
HEAD——与GET类似，但服务器不会在其响应中返回消息主体
TRACE——诊断目的
OPTIONS——要求服务器报告对某一特殊资源有效的HTTP方法
PUT——试图使用包含在请求主体中的内容
HTTP消息头
1. 常用消息头：
Connection——用户告诉通信的另一端，在完成HTTP传输后是否关闭TCP/IP连接
Content-Encoding——压缩响应以加快传输速度
Content-Length——规定消息主体的字节长度
Content-Type——规定消息主体的内容类型
Transfer-Encoding——为方便通过HTTP传输而对消息主体使用的任何编码
2. 请求消息头：Accept——告诉服务器客户愿意接受哪些内容
Accept-Encoding——告诉服务器客户愿意接受哪些内容编码
Authorization——用于为一种内置HTTP身份验证向服务器提交证书
Cookie——用于向服务器提交它以前发布的cookie
Host——用于指定出现在被请求的完整URL中的主机名称
If-Modified-Since——用于说明浏览器最后一次收到被请求的资源的时间
If-None-Match——用于指定一个实体标记
Referer——用于指示提出当前请求的原始URL
User-Agent——提供与浏览器或发生请求的其他客户端软件有关的信息
3. 响应消息头：Catch-Control——用于向浏览器传送缓存指令
ETag——用于指定一个实体标签
Expires——用户向浏览器说明消息主题内容的有效时间
Location——用户在重定向响应中说明重定向目标
Pragma——用户向浏览器传送缓存指令
Server——提供所使用的Web服务器软件的相关信息
Set-Cookie——用户向浏览器发布cookie，浏览器又在随后的请求中将其返回服务器
WWW-Authenticate——提供与服务器所支持的身份验证类型相关的信息
状态码：
1xx——提供信息
2xx——请求被成功提交
3xx——客户被重定向到其它资源
4xx——请求包含错误
5xx——服务器执行请求时遇到错误
服务器端功能：
1. 脚本语言（PHP、VBScript、Perl）
2. Web应用程序平台（ASP.NET、JAVA）
3. Web服务器（Apache、IIS、Netscape Enterprise）
4. 数据库（SQL、ORACLE、MySQL）
客户端功能：
HTML、超链接、表单、JavaScript、厚客户组件
编码方案：
URL编码、Unicode编码、HTML编码、Base64编码、十六进制编码
解析应用程序：枚举内容和功能：
1. Web抓取
2. 用户指定的抓取
3. 发现隐藏的内容
4. 应用程序页面与功能路径
5. 发现隐藏的参数
分析应用程序：
1. 确定用户输入进入点
2. 确定服务器端技术：
a) 提取版本信息
b) HTTP指纹识别
c) 文件扩展名
d) 目录名称
e) 会话令牌
f) 第三方代码组件
3. 确定服务器端功能：
a) 仔细分析请求
b) 推测应用程序的行为
4. 解析受攻击面
通过客户端传送数据：
1. 隐藏表单字段
2. HTTP Cookie
3. URL参数
4. Referer消息头
5. 模糊数据
6. ASP.NET ViewState
收集用户数据：HTML表单：
1. 长度限制
2. 基于脚本的确认
3. 禁用的元素
收集用户数据：厚客户端组件
1. Java applet（反编译Java字节码、字节码模糊处理）
2. ActiveX控件（逆向工程、利用输出函数、修改由控件处理的输入、托管代码反编译）
3. Shockwave Flash对象
安全处理客户端数据：
1. 通过客户传送数据
2. 确认客户生成的数据
3. 日志与警报
攻击验证机制
一、 验证技术：
1. 基于HTML表单的验证
2. 多元机制
3. 客户SSL证书或智能卡
4. HTTP基本和摘要验证
5. 使用NTML或Kerberors、整合Windows的验证
6. 验证服务
二、 验证机制设计缺陷：
1. 密码保密性不强：
a) 非常短或空白的密码
b) 以常用的字典词汇或名称为密码
c) 密码和用户名完全相同
d) 仍然使用默认密码
2. 蛮力攻击登录
3. 详细的失败消息
4. 证书传输易受攻击
5. 密码修改功能
6. 忘记密码功能
7. 记忆功能（“记住我”）
8. 用户伪装功能
9. 证书确认不完善
10. 非唯一性用户名
缺陷：
a) 在注册阶段或随后修改密码的过程中，共享同一个用户名的两个用户可能碰巧选择相同的密码
b) 及时由于失败登录尝试次数方面的限制，在其他地方不可能实施这种攻击，攻击者仍然可以利用这种行为成功实施蛮力攻击）
11. 可预测的用户名
12. 可预测的初试密码
13. 证书分配不安全
三、 验证机制执行缺陷：
1. 故障开放登录机制
2. 多阶段登录机制中的缺陷：
a) 使得仅拥有部分正常登录所需各种证书的攻击者能够成功登录
b) 攻击者若能在不同登录阶段的转换过程中干扰这些标记，就可以更改应用程序的行为，让他们只需部分证书即可通过验证，或者提升其权限
c) 应用程序可能认为每个阶段的用户身份不会发生变化
3. 不安全的证书储存
四、 保障验证机制的安全：
1. 使用可靠的证书：
a) 强制执行适当的最小密码强度要求
b) 使用唯一的用户名
c) 系统生成的任何用户名和密码应具有足够的随机性
d) 允许用户设置足够强大的密码
2. 安全处理证书：
a) 以不会造成非授权泄露的方式创建、保存和传送所有证书
b) 使用公认的加密技术保护客户与服务器之间的所有通信
c) 只使用POST请求向服务器传输证书
d) 客户端“记住我”功能应仅记忆非保密类数据
e) 使用一种密码修改工具，定期修改密码
f) 考虑在适当的地方使用下拉菜单而非文本字段截取用户的一些登录信息
3. 正确确认证书：
a) 确认完整的密码
b) 在登录处理过程中主动防御无法预料的事件
c) 对验证逻辑的伪代码和实际的应用程序源代码进行仔细的代码审查
d) 严格控制用户伪装功能，防止攻击者滥用它获得未授权访问
e) 对多阶段登录进行严格控制
4. 防止信息泄露：
a) 应用程序使用的各种验证机制不应通过公开的消息，或者通过从应用程序的其他行为进行推断，来揭示关于验证参数的任何信息
b) 由单独一个代码组件使用一条常规消息负责响应所有的失败登录尝试
5. 防止蛮力攻击：
a) 必须对验证功能执行的各种质询采用保护措施，防止攻击者试图使用自动工具响应这些质询
b) 使用无法预测的用户名，同时阻止用户名枚举
6. 防止滥用密码修改功能:
a) 应用程序应始终执行密码修改功能，允许定期使用的密码到期终止并允许用户修改密码
b) 只能从已通过验证的会话中访问该功能
c) 不应以任何方式直接提供用户名，或通过隐藏表单字段或cookie提供用户名
d) 应用程序应对密码修改功能加以保护，防止攻击者通过其他安全缺陷获得未授权访问
e) 为防止错误，新密码应输入两次
f) 使用一条常规错误消息告知用户现有证书中出现的任何错误
g) 使用“带外”方式通知用户其密码已被修改
7. 防止滥用账户恢复功能:
a) 精心设计的密码恢复机制需要防止账户被未授权方攻破，避免给合法用户造成任何使用中断
b) 绝对不要使用密码“暗示”之类的特性
c) 通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案
d) 为进一步防止未授权访问，可能会向用户提出一个次要质询，用户必须在使用密码重设功能前完成质询）
8. 日志、监控与通知:
a) 应用程序应在日志中记录所有与验证有关的事件
b) 应用程序的实时报警与入侵防御功能应对验证过程中的一场事件进行处理
c) 应以“带外”方式向用户通报任何重大的安全事件
d) 应以“带内”方式向用户通报经常发生的安全事件
攻击会话管理
执行会话的最简单、也是最常见的方法就是向每名用户发布一个唯一的会话令牌或标识符。
1. 会话管理机制中存在的两类漏洞：
a) 会话令牌生成过程中的薄弱环节
b) 在整个生命周期过程中处理会话令牌的薄弱环节
2. 会话替代方案
a) HTTP验证
b) 无会话状态机制
3. 结构化令牌的组成成分：
a) 账户用户名
b) 应用程序用来区分账户的数字标识符
c) 用户的电子邮件地址
d) 用户在应用程序中所属的组或扮演的角色
e) 日期/时间戳
f) 一个递增或可预测的数字
g) 客户的IP地址
4. 会话令牌处理中的薄弱环节：
1) 在网络上泄露令牌：
a) 一些应用程序在登录阶段选择使用HTTPS保护用户证书的安全，但在用户会话的其他阶段转而使用HYYP
b) 一些应用程序在站点中预先通过验证的区域使用HTTP，但从登录页面开始转换到HTTPS
c) 即使应用程序在用户成功登录后发布一个新令牌，并从登录页面开始使用HTTPS，但如果用户通过单击验证区域中的一个连接、使用“后退”按钮或者直接输入URL，重新访问一个预先验证的页面
d) 一些应用程序对应用程序内的全部静态内容使用HTTP
e) 即使应用程序在每一个页面都使用HTTPS，有些情况下，用户的令牌仍然通过HTTP传送
2) 在日志中泄露令牌：
a) 用户浏览器的日志
b) Web服务器的日志
c) 企业或ISP代理服务器的日志
d) 任何在应用程序主机环境中采用的反向代理的日志
e) 应用程序用户通过单击站外链接访问的任何服务器Referer日志
3) 令牌－会话映射易受攻击
4) 会话终止易受攻击
5) 客户暴露在令牌劫持风险之中：
a) 攻击者可通过跨站点脚本攻击查询用户的cookie，获得他们的会话令牌，然后将其传送给自己控制的任意服务器
b) 攻击者可以使用其他针对用户的攻击，以不同的方式劫持用户的会话
6) 宽泛的cookie范围
5. 保障会话管理的安全：
（1）生成强大的令牌
（2）在整个生命周期保障令牌的安全：
a) 令牌只能通过HTTPS传送
b) 绝不能在URL中传送会话令牌
c) 总是执行推出功能
d) 会话处于非活动状态一段时间后，执行会话终止
e) 防止并行登录
f) 尽可能限定应用程序会话cookie的域和路径范围
g) 严格审查应用程序的代码库，以确定并删除任何跨站点脚本漏洞
h) 不接受用户提交、但服务器并不认可的任何令牌
i) 在执行转帐之类的重要操作前，要求进行两步确认或重新验证
j) 不完全依赖HTTP cookie传送会话令牌
k) 成功验证后总是建立一个新的会话，以避免会话固定攻击的影响
（3）日志、监控与警报
攻击访问控制
1. 访问控制两大类：
a) 垂直访问控制
b) 水平访问控制
2. 常见的漏洞：
a) 完全不受保护的功能
b) 基于标识符的功能
c) 多阶段功能
d) 静态文件
e) 访问控制方法不安全
3. 保障访问控制的安全：
（1） 明显的缺陷：
a) 不要认为用户不知道用于指定应用程序资源的URL或标识符就无法访问这些资源
b) 不要信任任何用户提交的表示访问权限的参数
c) 不要认为用户将按设定的顺序访问应用程序页面
d) 不要相信用户不会篡改通过用户传送的数据
（2） 在Web应用程序中执行有效访问控制的最佳方法：
a) 仔细评估并记录每个应用程序功能单元的访问控制要求
b) 通过用户会话做出所有访问控制决定
c) 使用一个中央应用程序组件检查访问控制
d) 通过中央应用程序组件处理每个客户请求，确认提出请求的用户被允许访问他请求的功能和资源
e) 对于特别敏感的功能，确保只有特殊网络范围内的用户能够访问这些功能
f) 无论何时通过客户传送，指定用户所希望访问资源的标识符都容易遭到篡改，服务器只信任完整的服务器端数据
g) 对于安全性很关键的应用程序功能考虑对每笔交易执行重复验证和双重授权，进一步确保该功能不会被未授权方使用
h) 记录每一个访问敏感数据或执行敏感操作的事件
（3） 中央应用程序组件的优点：
a) 可增进应用程序访问控制的透明度
b) 可提高访问控制的可维护性
c) 可改善可适应性
d) 比在整个应用程序中逐步执行访问控制代码造成更少的错误和省略
4. 安全模型中应用各种有益的访问控制：
a) 编程控制
b) 自主访问控制
c) 基于角色的访问控制
d) 声明式控制
代码注入
1. 注入解释型语言
（1）解释型语言：一种在运行时由一个运行时组件解释语言代码并执行其中包含的指令的语言
（2）编译型语言：它的代码在生成时转换成机器指令，然后在运行时直接由使用该语言的计算机处理执行这些指令。
2. 注入SQL
（1） 利用一个基本的漏洞：
攻击者提交包含引号的输入终止SQL控制的字符串，然后编写任意的SQL修改开发者想要应用程序执行的查询
（2） 避开登录：
（3） 查明SQL注入漏洞：
a) 字符串数据
b) 数字数据
（4） 注入不同的语句类型：
a) SELECT语句
b) INSERT语句
c) UPDATE语句
d) DELECT语句）
e) UNION操作符
（5） “指纹识别”数据库
（6） 提取有用的数据
（7） 利用ODBC错误消息（仅使用与MS-SQL）：
a) 枚举表和栏名称
b) 提取任意数据
c) 使用递归
（8） 避开过滤：
a) 避免使用被阻止的字符
b) 避免使用简单确认
c) 使用SQL注释
d) 处理被阻止的字符串
e) 使用动态执行
f) 利用有缺陷的过滤
（9） 二阶SQL注入：
（10） 高级利用：
A. 获取数字数据
B. 使用带外通道
a) MS-SQL——使用OpenRowSet命令与外部数据库建立连接并在其中插入任何数据
b) Oracle——使用大量低权限用户可访问的默认功能建立带外连接
c) MySQL——SELECT…INTO OUTFILE命令可将任意一个查询的输出指向一个文件
d) 利用操作系统
e) 使用推论——条件式响应：引发条件性错误和使用时间延迟
C. SQL注入之外：扩大数据库攻击范围
D. 防止SQL注入部分有效的防御措施：
a) 将用户输入中的任何单引号配对，对它们进行转义
b) 使用存储过程完成全部数据库访问
c) 参数化查询（步骤）：
1） 应用程序指定查询结构，为用户输入的每个数据预留占符位
2） 应用程序指定每个占符位的内容
E. 深层防御：
a) 当访问数据库时，应用程序应尽可能使用最低权限的用户
b) 许多企业数据库包含大量默认功能，可被能够执行任意SQL语句的攻击者利用
c) 应评估、测试并及时安装供应商发布的所有安全补丁，以修复数据库软件本身存在的漏洞
3. 注入操作系统命令
a) 通过Perl注入
b) 通过JSP注入
c) 查找OS命令注入漏洞
d) 防止OS命令注入——完全避免直接调用操作系统命令
4. 注入web脚本语言
A. 动态执行漏洞：
1） PHP中的动态执行——eval函数
2） ASP中的动态执行——Exrcute函数
3） 查找动态执行漏洞
B. 文件包含漏洞：
1）远程文件包含
2）本地文件包含
3）查找文件包含漏洞
C. 防止脚本注入漏洞——避免将用户提交的输入或者来自用户的数据传送给任何动态执行或包含函数
5. 注入SOAP
A. SOAP（简单对象访问协议）是一种基于 XML 的协议，它被设计成在 WEB 上交换结构化的和固化的信息。
B. 查找并利用SOAP注入
C. 防止SOAP注入——在用户提交的数据被插入SOAP消息中的任何位置实施边界确认过滤
6. 注入XPath
A. XPath是一种用于导航XML文档并从中获取数据的解释性语言
B. 破坏应用程序逻辑
C. 谨慎XPath注入
D. 盲目XPath注入
E. 查找XPath注入漏洞
F. 防止XPath注入——提交可实施严格输入确认的简单数据
7. 注入SMTP
A. 操纵电子邮件消息头
B. SMTP命令注入
C. 查找SMTP注入漏洞
D. 防止SMTP注入：（根据一个适当的正则表达式检查电子邮件地址
E. 消息主题不得包括而内核换行符，并实施适当的长度限制
F. 禁止使用仅包含一个点字符的消息行）
8. 注入LDAP
A. LDAP（轻量级目录访问协议）用于访问网络中的目录服务
B. 注入查询属性
C. 修改查询过滤器
D. 查找LDAP注入漏洞
E. 防止LDAP注入
1） 只提交可实施严格输入确认的简单数据
2） 根据一份可接受字符“白名单”检查用户输入
3） 阻止任何可能破坏LDAP查询的字符包括（）,;*|&=
4） 拒绝而不是净化任何与白名单不匹配的输入
利用路径遍历
目录遍历(路径遍历)是由于Web服务器或Web应用程序对用户输入文件名称的安全性验证不足而导致的一种安全漏洞，使得攻击者通过HTTP请求和利用一些特殊字符就可以绕过服务器的安全限制，访问任意受限的文件，甚至执行系统命令。
1. 查找并利用路径遍历漏洞：
A. 确定攻击目标
B. 探查路径遍历漏洞
C. 避开遍历攻击障碍（输入过滤方法）：
1） 检查文件名参数中是否存在任何路径遍历序列
2） 确认用户提交的输入是否包含应用程序想要的后缀或前缀
D. 利用遍历漏洞——从包含有用信息的服务器上获取有益的文件，帮助优化针对其他漏洞的攻击
2. 防止路径遍历漏洞：
1） 对用户提交的文件名进行相关解码与规范化之后，应用程序应检查该文件名是否包含路径遍历序列或空字节
2） 应用程序应使用一个硬编码的、被允许访问的文件类型列表，并拒绝任何访问其他文件类型的请求
3） 对用户提交的文件名进行一切必要的过滤后，应用程序应使用适当的文件系统API确认，以及使用该文件名访问的文件是否位于应用程序指定的起始目录中
4） 应用程序可以使用一个chrooted环境访问包含被访问文件的目录，减轻大多数路径遍历漏洞造成的影响
5） 应用程序应将其路径遍历攻击防御机制与日志和报警系统机制整合在一起
攻击应用程序逻辑
逻辑缺陷的本质——代码中的简单错误以及几种应用程序核心组件互操作方面的极其复杂的漏洞
1. 现实中的逻辑缺陷：
1） 欺骗密码修改功能
2） 直接结算
3） 修改保险单
4） 入侵银行
5） 擦除审计追踪
6） 规避交易限制
7） 获得大幅折扣
8） 避免转义
9） 滥用搜索功能
10）利用调试消息
11）与登录机制竞赛
2. 避免逻辑缺陷：
1） 确保将应用程序各方面的设计信息清楚、详细地记录在文档中，以方便其他人了解设计者做出的每个假设
2） 要求源代码提供清楚的注释
3） 注意任何应用程序用户可完全控制的假设条件
4） 根据会话确定用户的身份和权限，不要根据请求的任何其他特性对用户的权限做出假设
5） 当根据用户提交的数据或者用户执行的操作更新会话数据时，仔细考虑更新后的数据可能会给应用程序的其他功能造成什么影响
攻击其他用户
1. 跨站点脚本
跨站脚本攻击（XSS）指的是恶意攻击者往Web页面里插入恶意html代码，当用户浏览该页之时，嵌入其中Web里面的html代码会被执行，从而达到恶意攻击用户的特殊目的。
反射型XSS是需要欺骗用户自己去点击链接才能触发XSS的，如在论坛发贴处的XSS就是持久型的XSS。
非持久性XSS，就是我们通常所说的反射型XSS，也是最常用，使用最广的一种方式。它通过给别人发送带有恶意脚本代码参数的URL，当URL地址被打开时，特有的恶意代码参数被HTML解析、执行。它的特点是非持久化，必须用户点击带有特定参数的链接才能引起。
持久性XSS，指的是恶意脚本代码被存储进被攻击的数据库，当其他用户正常浏览网页时，站点从数据库中读取了非法用户存入非法数据，恶意脚本代码被执行。这种攻击类型通常在留言板等地方出现。
1）反射性XSS漏洞与保存型XSS漏洞的区别：
反射性XSS漏洞——攻击者必须以某种方式诱使受害者访问他精心设计的URL
攻击者可能会说服用户登录，然后点击它们提供的一个连接，从而劫持用户的对话
保存型XSS漏洞——攻击者只需要等待受害者浏览已被攻破的页面或功能
攻击者能保证受害用户在他实施攻击时已经在访问应用程序
2）基于DOM的XSS漏洞：利用此漏洞通常需要攻击者诱使一名用户访问一个包含恶意代码的专门设计URL，并由服务器响应那个使得恶意代码得以执行的特殊请求
3）连接XXS与其他攻击
4）XSS攻击有效载荷：
a) 虚拟置换
b) 注入木马功能
c) 诱使用户执行操作
d) 利用信任关系
e) 扩大客户端攻击范围：
i. 记录键击
ii. 截获剪切板内容
iii. 窃取历史记录与搜索查询
iv. 枚举当前使用的应用程序
v. 对本地网络进行端口扫描
vi. 攻击其他网络主机
vii. 利用浏览器漏洞
5）XXS攻击的传送机制：
a) 传送反射型与基于DOM的XSS攻击
b) 传送保存型XSS攻击
6）查找并利用XSS漏洞：
A. 查找并利用反射型XSS漏洞：攻击者截获一名通过验证的用户的会话，劫持会话后，攻击者就可以访问该用户经授权访问的所有数据和功能
B. 服务器对输入的处理：
i. 应用程序发现一个攻击签名，完全阻止了输入
ii. 应用程序已经接受了输入，但对攻击字符串进行了某种净化或编码
iii. 应用程序把攻击字符串截短至某个固定的最大长度
C. 查找并利用保存型XSS漏洞：攻击者至少需要向应用程序提出两个请求，在第一个请求中传送一些专门设计的数据，其中包含恶意代码，在第二个请求中，一名受害者查看某个包含攻击者的数据页面，这是恶意代码开始执行。
D. 查找并利用基于DOM的XSS漏洞
7）HttpOnly cookie与跨站点追踪：
HttpOnly cookie：HttpOnly cookie是某些浏览器所支持的一种防御机制，使用HTTP-only Cookie后，Web 站点就能排除cookie中的敏感信息被发送给黑客的计算机或者使用脚本的Web站点的可能性。为了降低跨站点脚本攻击带来的损害，通常需要将HTTP-only Cookie和其他技术组合使用。如果单独使用的话，它无法全面抵御跨站点脚本攻击。
跨站点追踪（XST）：跨站点追踪（XST）是一种攻击技巧，有时可以利用它避开HttpOnly cookie提供的保护，允许客户端JavaScript访问标记为HttpOnly的cookie值。
8）防止XSS攻击：
a) 防止反射型与保存型XSS漏洞：
i. 确认输入
ii. 确认输出
iii. 消除危险的插入点
b) 防止基于DOM的XSS漏洞：
i. 确认输入
ii. 确认输出
c) 防止XST：
i. 将所有cookie标记为HttpOnly
ii. 同时禁用TRACE方法
2. 重定向攻击
常用的重定向方式有:：301 redirect、 302 redirect 与 meta fresh。
(一)301 redirect:：301代表永久性转移，301重定向是网页更改地址后对搜索引擎友好的最好方法，只要不是暂时搬移的情况，都建议使用301来做转址。
(二)302 redirect： 302代表暂时性转移，各大主要搜索引擎均加强了打击力度，即使网站客观上不是spam，也很容易被搜寻引擎容易误判为spam而遭到惩罚。
(三)meta fresh:：通过网页中的meta指令，在特定时间后重定向到新的网页，如果延迟的时间太短(约5秒之内)，会被判断为spam。
A. 查找并利用重定向漏洞：
1）HTTP重定向使用一条状态码为3xx的消息与一个指定重定向目标的Location消息头
2）HTTP Refresh消息头可用于在一个固定时间间隔后重新加载一个任意URL页面，其内容可为0，以立即触发一个重定向
3）HTML<meta>标签可用于复制任何HTTP消息头的行为，因此可用于建立重定向
4）JavaScript中有各种API可将浏览器重定向到任意一个URL
B. 避开攻击中的障碍：
1）阻止绝对URL
2）附加一个绝对前缀
C. 防止重定向漏洞：
1）应用程序应在所有重定向中使用相对URL，重定向页面应严格确认它受到的URL是一个相对URL
2）应用程序应在所有重定向中使用相对于Web根目录的URL
3）应用程序应对所有重定向使用绝对URL，重定向页面在发布重定向之前，应确认用户提交的URL，并拒绝任何其他输入
3. HTTP消息头注入
1）利用消息头注入漏洞：
a) 注入cookie
b) 传送其他攻击
c) HTTP响应分割
2）防止消息头注入漏洞：
a) 确认输入
b) 确认输出
4. 框架注入
1）利用框架注入——步骤：
a) 攻击者创建一个看似无害的Web站点，其中包含一段每隔10s就会自动运行的脚本，并尝试使用它覆写main_display框架的内容
b) 攻击者或者等待用户浏览自己创建的站点，或者使用其他方法诱使用户访问该站点
c) 一名用户浏览攻击者创建的看似无害的Web站点，如果同时访问原无害网站，那么原网站窗口中的main_display的框架会被攻击者的木马内容覆盖，用户输入的任何数据都将被提交给攻击者
2）防止框架注入：
a) 应用程序不要求不同的框架互相通信
b) 使用命名框架，但在每个会话中使用不同的框架，并且使用无法预测的名称
5. 请求伪造
1）本站点请求伪造：利用保存型XSS漏洞的常见攻击有效载荷
2）跨站点请求伪造（XSRF）：要求使用与前面描述的框架注入攻击类似的传送机制
3）利用XSRF漏洞：出现在HTTP cookie被用于传送会话令牌的地方
4）防止XSRF漏洞：不完全依赖于cookie传送会话令牌
6. JSON劫持
1） JSON：一种可用于序列化任意数据，并能被JavaScript注释器直接处理的简单数据交换格式。易于人阅读和编写，同时也易于机器解析和生成。
2） 攻击JSON：覆写数组构造器，执行一个回调函数
3） 查找JSON劫持漏洞：JSON劫持属于一种跨站点请求伪造漏洞，攻击者可以利用JSON劫持获取其他域中的任意数据，不仅仅是执行跨域操作
4） 防止JSON劫持：
a) 应用程序应使用标准的反XSRF防御阻止跨域请求访问敏感数据
b) 当应用程序从它自己的域中获取JSON对象时，并不仅限于使用<script>标签包含这个对象
c) 应用程序可以使用POST请求完成这项任务
7. 会话固定
1） 攻击者将一个特殊的令牌固定到一名目标用户身上所使用的两种技巧：
a) 如果应用程序在一个URL参数中传送会话令牌，那么攻击者只需向受害者传送应用程序向他发布的相同URL
b) 如果应用程序使用HTTP cookie或HTML表单中的隐藏字段传送会话令牌，那么攻击者可以利用一个已知的XSS或消息头注入漏洞，在用户浏览器中设置这些值
2） 查找并利用会话固定漏洞：
a) 应用程序向每名未通过验证的用户发布一个匿名会话令牌。在用户登录后，它并不发布新令牌，相反，他们现有的会话被升级为通过验证的会话。
b) 应用程序并不向匿名用户发布令牌，只有用户成功登录后，应用程序才向用户发布一个令牌。但是，如果一个用户使用通过验证的令牌访问登录功能，并使用不同证书登录，应用程序不发布新令牌，相反，前面通过验证会话的用户身份转换为第二用户身份
3） 防止会话固定漏洞：应用程序采用每页面令牌强化主会话令牌
8. 攻击ActiveX控件
1） ActiveX控件中对攻击者有用的漏洞：
a) 由于ActiveX控件通常以C/C++之类的本地语言编写，很可能存在一些典型的软件漏洞
b) 许多ActiveX控件中包含一些本质上存在风险、易于遭到滥用的方法
2） 防止ActiveX控件漏洞：
a) 应对控件进行以安全为中心的源代码审查与渗透测试，以确定缓冲区溢出之类的漏洞
b) 控件不得暴露任何使用用户可控制的输入调用外部文件系统或操作系统、本质上存在风险的方法
9. 本地隐私攻击
1） 持久性cookie
2） 缓存Web内容
3） 浏览历史记录
4） 自动完成
5） 防止本地隐私攻击：应使用适当的缓存指令防止浏览器保存敏感数据
10.高级利用技巧
1） 利用Ajax
AJAX 不是一种新的编程语言，而是一种用于创建更好更快以及交互性更强的 Web 应用程序的技术。AJAX 在浏览器与 Web 服务器之间使用异步数据传输（HTTP 请求），这样就可使网页从服务器请求少量的信息，而不是整个页面。AJAX能够在后台执行灵活而又强大的操作，对于企图攻击应用程序其他用户的攻击者特别有吸引力。
2） 反DNS Pinning
3） 浏览器利用框架
定制攻击自动化
1. 应用定制自动化攻击：
1）枚举标识符
2）获取数据
3）Web应用程序模糊测试
2. 定制自动化攻击技巧的用途：
1）显著提高攻击效率
2）通过专门设计的特殊请求，以一次一个数据的速度获取信息，从而提取出有用的或敏感的数据
3. 枚举有效的标识符：基本步骤：
1）查找请求/响应对：
i. 请求的参数中包含所针对的标识符
ii. 当改变这个参数时，服务器对这个请求的响应也会发生响应的变化
2）向应用程序提交大量自动请求，循环浏览所有潜在的标识符
3）监控应用程序对请求的响应，查找表示提交有效标识符的“触点”
探测触点：
a) HTTP状态码
b) 响应长度
c) 响应主体
d) Location消息头
e) Set-Cookie消息头
f) 时间延迟
编写攻击脚本
JAttack
4. 获取有用的数据
5. 常见漏洞模糊测试：
a) 无论每个参数的正常功能是什么，或者应用程序希望受到何种类型的数据，在这种攻击中，往往需要提交与测试应用程序每个页面的每一个参数相同的攻击有效载荷
b) 与其监控应用程序的响应，在其中查找特殊的指标，还不如系统性地截取尽可能多的数据并对其进行审查，确定攻击字符串在应用程序中触发反常行为的情形，然后做深入调查
6. 整合全部功能：Burp Intruder
a) 安置有效载荷
b) 选择有效载荷
c) 配置响应分析
d) 攻击一：枚举标识符
e) 攻击二：获取信息
f) 攻击三：应用程序模糊测试
利用信息泄露
1. 利用错误消息：
a) 错误消息脚本
b) 栈追踪
c) 详尽的调试消息
d) 服务器与数据库消息
e) 使用公共信息
f) 制造详尽的错误消息
2. 栈追踪提供大量有用的消息：
l 会说明错误发生的准确原因，可以根据这些信息调整输入内容，避开错误条件，继续实施攻击
l 调用栈经常会引用应用程序使用的大量库和第三方代码组件，可以查阅这些组件的文档资料，了解它们的常规行为与假设
l 调用栈中包含用于处理请求的所有权代码组件的名称，了解这些组件的命名方案及相互关系有助于推断应用程序的内部结构与功能
l 栈追踪中通常包含行号，可以利用这些行号探查并理解每个应用程序组件的内部逻辑
l 错误消息中常常包含与应用程序及其运行环境有关的其他信息
3. 详尽的调试消息中包含的信息：
l 可通过用户输入操纵的关键会话变量值
l 数据库等后端组件的主机名称与证书
l 服务器中的文件与目录名称
l 嵌入在有意义的会话令牌中的信息
l 用于保护通过客户传送的数据的加密密钥
l 在本地代码组件中出现的异常调试信息
4. 收集公布的信息：应用程序可能向用户公布的敏感信息包括：
a) 有效用户名、账号与文档ID列表
b) 用户个人资料，包括用户角色与权限、最后登录日期与账户状态
c) 用户当前使用的密码
d) 包含在日志文件中的信息
e) 客户端HTML源代码中与应用程序有关的细节
5. 使用推论：
a) 注册功能允许在选择已经存在的用户名时根据出现的错误消息枚举出已注册的用户名
b) 搜索引擎允许推断出未获授权就可直接查看的编入索引的文档内容
c) 在盲目SQL注入漏洞中，可通过给现有的查询增加一个二进制条件，一次次提取信息
6. 防止信息泄露：
a) 使用常规错误消息
b) 保护敏感信息
c) 尽量减少客户端信息泄露
攻击编译型应用程序
1. 缓冲区溢出漏洞：
应用程序将用户可控制的数据复制到一个不足以容纳他们的内存缓存区中，就会出现缓冲区溢出漏洞，导致邻近的内存被用户数据覆盖。攻击者可以根据漏洞的本质利用它在服务器上运行任意代码或执行其他为授权的操作。
a) 栈溢出
b) 堆溢出
c) “一位偏倚”溢出
2. 整数漏洞：
应用程序在执行某种缓冲区操作前对一个长度值运用某种算法，但却没有考虑到编译器与处理器整数计算方面的一些特点，能够就会出现与整数有关的漏洞。
a) 整数溢出
b) 符号错误
3. 格式化字符串漏洞：
用户可控制的输入被当作格式化字符串参提交给一个接受可能被滥用的格式说明符的函数，就会产生格式化字符串漏洞。
攻击应用程序架构
1. 分层架构：
a) 常用的三层架构的层次：
i. 展现层，执行应用程序的界面
ii. 应用程序层，执行核心应用程序逻辑
iii. 数据库，存储并处理应用程序数据
b) 攻击分层架构：
i. 可以利用不同层之间的信任关系扩大攻击范围，从一个层侵入到另一个层
ii. 如果不同层之间没有完全隔离，就可以利用某一层存在的缺陷直接破坏另一层实施的安全保护
iii. 局部攻破一个层后，就可以直接攻击其它层的基础结构，从而将攻击扩大到其它层
c) 保障分层结构的安全：
i. 尽量减少信任关系：
l 应用程序服务器层应对特殊的资源与URL路径实施基于角色的访问控制
l 数据库服务器层可以为应用程序的不同用户和操作提供各种权限的账户
l 所有应用程序组件可以使用拥有正常操作所需的最低权限的操作系统帐户运行
ii. 隔离不同的组件：
l 一个层不得读取或写入其它层使用的文件
l 对于不同基础架构组件之间的网络级访问进行过滤，仅允许需要与不同应用程序层彼此通信的服务
iii. 应用深层防御：
l 应根据配置与漏洞补丁，把每台主机上的技术栈的各个层面进行安全强化
l 应对保存在任何应用程序层中的数据进行加密，以防止攻破该层的攻击者轻松获得这些数据
2. 共享主机与应用程序服务提供商：
a) 虚拟主机
b) 共享的应用程序服务
c) 攻击共享环境：
i. 针对访问机构的攻击
ii. 应用程序的攻击：
1）预留后门
2）易受攻击的应用程序间的攻击：
l 攻击者可以利用某个应用程序中SQL注入漏洞在共享数据库中执行任意SQL查询
l 攻击者可以利用某个应用程序中的路径遍历漏洞读取或写入服务器文件系统中的任意文件
l 攻击者可以利用某个应用程序中的命令注入漏洞攻破服务器以及服务器运行的其他应用程序
3）ASP应用程序组件间的攻击
d) 保障共享环境的安全：
i. 保障客户访问的安全：
l 远程访问机制应实施严格的身份确认，使用难以窃听的加密技术，并进行充分的安全强化
l 仅允许个体用户最低的访问权限
l 如果使用一个定制的应用程序提供客户访问，该应用程序必须蛮族严格的安全需求，并根据它在保护共享环境安全中发挥的作用进行测试
ii. 隔离客户功能：
l 每名客户的应用程序应使用一个独立的操作系统账户访问文件系统，该账户仅拥有读取与写入应用程序文件路径的权限
l 强大系统功能与命令的访问权限应仅限于操作系统等级，且应只分配所需的最低权限
l 应在任何共享数据库中实施相同的保护措施
iii. 隔离共享应用程序中的组件
攻击Web服务器
1. Web服务器配置缺陷
a) 默认证书
b) 默认内容：
l 调试功能
l 样本功能
l 强大的功能
c) 目录列表：获得目录列表有利于攻击者对应用程序进行攻击的原因：
l 许多应用程序并不对它们的功能与资源实施正确的访问控制，而是依赖于攻击者忽略用于访问敏感内容的URL
l 日志、备份文件、旧版脚本等文件与目录经常被无意一楼在服务器的WEB根目录中
d) 危险的HTTP方法
e) Web服务器作为代理服务器：
l 攻击者可以使用该服务器攻击因特网上的第三方系统
l 攻击者可以使用代理服务器连接阻止内部网络中的任意主机
l 攻击者可以使用代理服务器反向连接代理服务器主机上运行的其他服务器，突破防火墙限制，并利用信任关系避开身份验证
f) 虚拟主机配置缺陷
g) 保障web服务器配置的安全：
l 修改所有默认证书，删除任何不必要的账户
l 在web根目录的相关路径上应用访问控制列表，或者对非标准端口设置防火墙，阻止公众访问管理接口
l 删除所有事先商业目的并不完全需要的默认内容与功能
l 如果需要保留任何默认功能，尽量对其进行强化，禁用不必要的选项与行为
l 在所有web目录中查找目录列表
l 除应用程序常用方法外，禁用其他所有方法
l 取保没有将web服务器配置为代理服务器
l 如果web服务器支持虚拟主机，确保在默认主机上实施服务器采用的所有安全强化措施
2. Web服务器软件漏洞
a) 缓冲区溢出漏洞：
l Microsoft IIS ISAP扩展
l Apache分块编码溢出
l Microsoft IISWebDav溢出
l iPlanet搜索溢出
b) 路径遍历漏洞：
l Accipiter DirectServer
l Alibaba
l Cisco ACS Acme.sever
l McAfee EPolicy Orcestrator
c) 编码与规范化漏洞：
l Allaire JRun目录列表漏洞
l Microsoft IIS Unicode路径遍历漏洞
l 避开Oracle PL/SQL排除列表
d) 查找web服务器漏洞
e) 保障web服务器软件的安全：
l 选择记录良好的软件
l 应用供应商发布的补丁
l 实施安全强化
l 监控新的漏洞
l 使用深层防御
查找源代码中的漏洞
1. 代码审查方法：“黑盒”测试与“白盒”测试：
a) “黑盒”测试方法：主要从外部攻击应用程序，并监控其输入与输出，而之前并不了解它的内部工作机制
b) “白盒”测试方法：需要分析应用程序的内部运作，查阅所有设计文档、源代码与其他资料
c) 代码审查方法——步骤：
i. 从进入点开始追踪用户向应用程序提交的数据，审查负责处理这些数据的代码
ii. 在代码中搜索表示存在常见漏洞的签名，并审查这些签名，确定某个漏洞是否确实存在
iii. 对内在危险的代码进行逐行审查，理解应用出程序的逻辑，并确定其中存在的所有问题
2. 常见漏洞签名：
a) 跨站点脚本
b) SQL注入
c) 路径遍历
d) 任意重定向
e) OS命令注入
f) 后门密码
g) 本地代码漏洞：
l 缓冲区溢出漏洞
l 整数漏洞
l 格式化字符串漏洞
h) 源代码注释
3. JAVA平台
a) 确定用户提交的数据：通过javax.servlet.http.HttpServletRequest接口获取用户提交的输入
b) 会话交互：使用javax.servlet.http.HttpSession接口保存和检索当前会话中的信息
c) 潜在危险的API：
l 文件访问
l 数据库访问
l 动态代码执行
l OS命令执行
l URL重定向
l 套接字
d) 配置Java环境
4. ASP.NET
a) 确定用户提交的数据：通过System.Web.HttpRequest类获取用户提交的输入
b) 会话交互：以各种方式与用户会话进行交互，以保存和检索信息
c) 潜在危险的API：
l 文件访问
l 数据库访问
l 动态代码执行
l OS命令执行
l URL重定向
l 套接字
d) 配置ASP.NET环境
5. PHP
a) 确定用户提交的数据：使用一系列数组变量保存用户提交的数据
b) 会话交互：使用$_SESSION数组保存和检索用户会话中的信息
c) 潜在危险的API：
l 文件访问
l 数据库访问
l 动态代码执行
l OS命令执行
l URL重定向
l 套接字
d) 配置PHP环境：
i. 使用全局变量注册
ii. 安全模式
iii. Magic Quotes
6. Perl
a) 确定用户提交的数据
b) 会话交互：Perl模块CGISession.pm对模块CGI.pm进行扩展，为会话追踪与数据存储提供支持
c) 潜在危险的API：
l 文件访问
l 数据库访问
l 动态代码执行
l OS命令执行
l URL重定向
l 套接字
d) 配置Perl环境
7. JavaScript
8. 数据库代码组件：
a) SQL注入
b) 调用危险的函数：
l MS-SQL与Sybase中功能强大的存储过程，使用它们可执行命令或访问注册表等
l 用于访问文件系统的函数
l 连接到数据库以外的库的用户定义的函数
l 可访问网络的函数
9. 代码浏览工具：
为进行有效的代码审查，最好使用一款只能工具浏览代码，该工具能够理解各种语言使用的代码结构，提供与特定API和表达式有关的上下文信息，并能够方便地进行导航
Web应用程序黑客工具包
1. Web浏览器
2 Internet Explorer
2 FireFox
2 Opera
2. 集成测试套件：
2 Burp
2 Paros
2 WebScarab
a) 工作原理——套件核心组成：
i. 拦截代理服务器
l 配置浏览器
l 拦截代理服务器与HTTPS
l 共同特性
ii. Web应用程序爬虫
l 使用通过拦截代理服务器访问的URL自动更新站点地图
l 被动抓取代理服务器处理的内容，从中解析出链接
l 以表格和树状形式呈现所有发现的内容，方便对这些结果进行搜索
l 对自动抓取的范围进行细化控制
l 自动解析HTTP表单，脚本，文档和图像
l 解析JavaScript内容，查找URL与资源名称
l 使用适当的参数根据用户的知道自动提交表单
l 探查自定义的“文件未发现”响应
l 自动获取所有枚举出的目录的根目录
l 自动处理和使用由应用程序发布的cookie，在通过验证的会话中进行抓取
l 自动测试每个页面的会话依赖性
l 发布请求时自动使用正确的Referer消息头
l 控制在自动抓取过程中使用的HTTP消息头
l 控制提出的自动抓取请求的速度和顺序，避免请求令攻击目录崩溃
iii. 应用程序漏洞测试器或扫描仪
l 自动扫描常见漏洞
l 手动配置常见漏洞扫描
l 一组内置的攻击有效载荷和易变函数，以用户定义的方式生成任意有效载荷
l 能够保存扫描响应数据，将其用在报告中，或者合并到其他攻击中
l 查看和分析响应的定制化功能
l 从应用程序的响应中提取有用数据的功能
l 分析cookie和其他令牌，从中查找所有序列的功能
iv. 手动请求工具
v. 各种共享功能与实用工具
b) 特性比较：
i. Burp套件：
拥有非常强大的功能，而且提供一个直观、用户友好的界面。拥有功能全面的Web应用程序爬虫，该爬虫能够解析表单和JavaScript，并能够根据用户的知道自动提交表单。
Intruder工具是Burp的优势所在，它能够以最细化、最简单的方法访问它生成的请求与响应，允许组合利用人类智能与计算机自动控制。
ii. Paros套件：
Paros爬虫工具基本上就是一个Web站点爬虫，它通过代理服务器请求的URL更新抓取结果。拥有一个内置的漏洞扫描器，使用它可以确定一些具有明显签名的常见漏洞
l 基本的反射型跨站点脚本漏洞
l 一部分SQL注入漏洞
l 激活自动完成的表单
l 旧版文件
Paros的优点在于使用已经通过代理服务器的请求作为攻击的基础。
Paros的其他功能：保存和加载测试任务，输入客户SSL证书，访问使用这些证书的Web应用程序
iii. WebScarab套件：
WebScarab包含一个简单的漏洞测试器，能够根据用户提供的模糊测试字符串对参数进行一定程度的操纵，并提供测试结果的基本信息。WebScarab能保存和加载测试任务，输入客户SSL证书，访问使用这些证书的Web应用程序。WebScarab拥有一个基本的拦截代理服务器。
c) 拦截代理服务器替代工具：
l Tamper Data
l TamperIE
3. 漏洞扫描器：
a) 扫描器探测到的漏洞：
l 反射型跨站点脚本漏洞
l 一些SQL注入漏洞
l 一些路径遍历漏洞
l 一些命令注入漏洞
l 直接目录列表
l 框架注入、范围宽泛的cookie、激活自动完成的表单等漏洞
b) 扫描器的内在限制：
l 每一个Web应用程序都各不相同
l 扫描器不理解语法
l 扫描器不会“不会”处理
l 扫描器并无直觉
c) 扫描器面临的技术挑战：
l 验证与会话处理
l 危险的后果
l “个性化”功能
l 其他自动控制挑战
d) 当前产品：
l AppScan
l WebInspect
e) 使用漏洞扫描器：
l 了解扫描器能够确定和不能确定的漏洞类型
l 熟悉扫描器的功能，知道如何配置，对某个应用程序进行有效扫描
l 在运行扫描器之前全面了解目标应用程序，以充分利用扫描器功能
l 了解抓取强大的功能和自动探查危险漏洞蕴含的风险
l 始终手动核实扫描器报告的所有潜在的漏洞
4. 其他工具：a) Nikto：可确定Web服务器上默认或常见的第三方内容，包含一个大型文件和目录数据库，其中含有Web服务器上的默认页面与脚本以及第三方软件。
b) Hydra：密码猜测工具，可用于攻击Web应用程序常用的基于表单的验证。
c) 定制脚本：
l 应用程序使用一种不常见的会话处理机制
l 希望利用一个需要重复执行几个特殊步骤的漏洞，将在一个响应中获取的数据合并到随后的请求中
l 如果确定一个潜在恶意的请求，应用程序会立即终止会话
d) 可以从脚本调用的简单工具：
l Wget
l Curl
l Netcat
l stunnel
作者: inhidgehila 时间: 2014-10-15 11:51
呵呵 高兴成什么样了啊!!!
作者: oxdbw 时间: 2014-10-15 11:55
有现实中的偶在这...不佩服.............佩服电影里的....
作者: ofbnbaiinfnh 时间: 2014-10-15 12:21
我的我的 忘记了 呵呵
作者: ofbnbaiinfnh 时间: 2014-10-15 12:27
我起来了 哈哈 刚才迷了会
作者: kjlqiyjws 时间: 2014-10-15 12:41
哪个正常的人能崇拜一只蟑螂呢?
作者: ofbnbaiinfnh 时间: 2014-10-21 22:40
(⊙o⊙)…好长啊，我虽然回复不了那么多字，但十五字还是有的。
作者: kjlqiyjws 时间: 2014-10-21 22:40
今天没事来逛逛
作者: ffuip 时间: 2014-10-21 22:41
原来...发神经是这样的啊...
作者: oxdbw 时间: 2014-12-3 13:10
什么啊
作者: inhidgehila 时间: 2014-12-3 13:27
怎么就没人拜我为偶像那??
作者: inhidgehila 时间: 2014-12-3 13:36
都看了，这帖子有意思。
作者: jckie 时间: 2014-12-3 13:53
教教我怎么seo
作者: wwdu926a 时间: 2014-12-4 16:40
要相信自己~智商为0
作者: tohme 时间: 2014-12-4 16:41
看起来好~~像啊~~~~~
作者: seazvyt 时间: 2014-12-4 16:43
机会就像水中的鱼，耐心等待就能上钩。
作者: seazvyt 时间: 2017-4-11 16:02
貌似我没看懂那~~~
作者: effoggikeftor 时间: 2017-4-11 16:02
你该这么说~~
作者: effoggikeftor 时间: 2017-4-11 16:05
哈哈 我支持你
作者: Acropozelan 时间: 2017-4-11 16:11
终于看完了~~~
| 欢迎光临 得知互动 (https://bbs.dezhifl.com/) |
Powered by Discuz! X3.4 |