1558人加入学习
(3人评价)
Web安全基础
价格 ¥ 99.00
该课程属于 CISP-PTE预习课程 请加入后再学习

WEB应用安全开发与测试

web安全漏洞原理、渗透测试、漏洞整改、安全开发

目录:

  • web安全现状
  • 现网漏洞分析
  • 漏洞形成原理
  • 漏洞危害
  • 安全漏洞测试方法
  • 漏洞整改办法
  • 渗透思路与测试方法概括
  • 安全开发设计

 

web安全现状

  • 复杂应用系统代码量大、开发人员多、难免出现疏忽;
  • 系统屡次升级、人员频繁变更,导致代码不一致;
  • 历史遗留系统、试运行系统等多个web系统共同运行于同一台服务器上;
  • 开发人员未经过安全编码培训;
  • 定制的开发系统的测试程度不如标准的产品;
  • 当前web是重点攻击目标

 

SQL injection-分析

  • SQL注入本质:字面量部分被当做SQL语句执行,数据与代码的界限被打破
  • 发生场景:select、insert、update、delete等有涉及SQL语句
  • 攻击对象:服务端

 

SQL injection-案例与危害

  • 漏洞危害:将整个数据库拖走【爆库名、爆表名、爆字段名、爆字段内容】、提权获取服务器控制权限
  • 测试思路:打破字面量(字符型、int型),尝试是否可改变SQL语句的构造。

 

通过注入神器SQLMAP替代手工注入,如执行:--tables -D "BASSWEB",得到所有的BASSWEB库下面的所有表名。通过该工具可以完成脱库。

 

SQL injection-整改建议

  • 参数化查询,做到了数据与代码分离,是防御sql注入的最佳方式

备注:SQL注入攻击的字符串好比笼中的狮子,无论攻击字符串多危险,只要它被解析为字面量就相安无事

 

  • 过滤器:对输入的特殊字符进行过滤包括:<> “” \ % ; () & + - ' 乃至select 、order by 等sql关键字进行过滤。

优点:整改量小,且不需要去找出每个注入点就可以整改。

缺点:可能影响应用

 

XML injection

  • 和SQL注入原理一样,XML是存储数据的地方,在查询或修改时,如果没有做转义,直接输入或输出数据,都将导致XML注入漏洞。攻击者可以修改XML数据格式,增加新的XML节点,对数据处理流程产生影响。

 

满足XML注入攻击的两个条件:

1)用户能控制数据的输入

2)程序拼凑了数据

 

解决方案:

在XML保存和展示前,对用户输入数据中包含的“语言本身的保留字符”进行转义即可。

 

& --> &amp;

< --> &lt;

> -->&gt;

"-->&quot;

'-->&#39;

 

code injection

  • Web应用中允许接收用户输入的一段代码,之后在web应用服务器上执行这段代码,并返回给用户。所以恶意用户可以写一个远程控制木马,直接获取服务器控制权限。
  • 代码注入与命令注入往往都是由一些不安全的函数或者方法引起的,其中典型的代表是eval();
  • 执行代码的参数,或文件名,禁止和用户输入相关,只能由开发人员定义代码内容,用户只能提交“1、2、3”参数,代表相应代码。

 

System command injection

  • 系统命令执行攻击,是指代码中有一段执行系统命令的代码,但是系统命令需要接收用户输入,恶意攻击者可以通过这个功能直接控制服务器。
  • 所有需要执行的系统命令,必须是开发人员定义好的,不允许接收用户传来的参数,加入到系统命令中去。

 

XSS(跨站)--漏洞本质

  • XSS本质:HTML注入,混淆了原本语义,产生了新的语义(反射型与存储型)
  • XSS发生场景:HTML标签、HTML属性、script标签、事件、CSS、URL
  • XSS渗透思路:尝试改变语义,执行用户的JS
  • 攻击对象:与SQL注入攻击的是服务端不同,XSS攻击对象为用户。

 

XSS防御--利用OWASP的API

  • 使用带有httpOnly属性的cookier(不能防止XSS,但能防止cookie窃取)
  • 在HTML标签中输出,对变量使用HtmlEncode
  • 在HTML属性中输出,对变量使用HtmlEncode
  • 在<script>标签中输出,对变量使用javascriptEncode
  • 在事件中输出,对变量使用javascriptEncode
  • 在CSS中输出,推荐使用OWASP ESAPI中的encodeForCSS()函数
  • 在地址中输出,应先检查变量是否以http开头,如果不是则自动添加,然后在对变量进行URLencode
  • 处理富文本,使用XSS规则引擎进行编码过滤,例如OWASP的一个开源项目Anti-Samy

XSS防御--过滤器

  • 过滤器:对单引号、双引号、尖括号、括号、& 、/ 等特殊字符进行过滤,更进一步甚至可以对script、iframe等进行过滤。

优点:简单、易处理

缺点:由于方法简单暴力,因此可能影响应用

 

  • 与应用冲突的建议

抓取系统中所有有特殊字符输入需求的页面,形成白名单,然后接受风险或根据应用规格改写针对这类页面的过滤器

根据功能需求,完善过滤器,原则是只要无法去执行用户拼接进去的代码

 

  • 注意

测试过程有发现,直接无法执行,但是进行URL编码后可以执行

 

伪造跨站请求(CSRF)

  • 漏洞原理:通过伪装来自受信任用户的请求改变服务端数据(见到杀人)
  • 攻击条件:重要操作的所有参数都是可以被攻击者猜解到
  • 渗透思路:对改变服务端数据的操作中(更改用户信息),如果没有随机数,都会产生类似攻击。
  • 漏洞攻击过程示意图:

 

伪造跨站请求(CSRF)--防御

  • Anti CSRF Token:Token是根据“不可预测性原则”设计的方案
  • 在用户登录时,设置一个CSRF的随机TOKEN,同时种植在用户的cookie中,当用户浏览器关闭、或用户再次登录、或退出时,清除token。
  • 在表单中,生成一个隐藏域,它的值就是COOKIE中随机TOKEN。
  • 表单被提交后,就可以在接收用户请求的web应用中,判断表单中的TOKEN值是否和用户COOKIE中的TOKEN值一致,如果不一致或没有这个值,就判断为CSRF攻击,同时记录攻击日志
  • 备注:token需要足够随机,如果要同时抗重放攻击,那该TOKEN就要一次失效。

 

url redirect

  • 漏洞描述:WEB应用程序接收到用户提交的URL参数后,没有对参数做“可信任URL”的验证,就向用户浏览器返回跳转到该URL的指令。
  • 漏洞危害:形成自由重定向(钓鱼攻击)或HTTP消息头注入
  • 渗透思路:将重定向的URL改为自己指定的URL(网络可达)
  • 可跳转到任一一个网站,非法者可利用这进行钓鱼,搜集合法用户的帐号密码等等。

 

url redirect --防御

  • 为确保用户点击的URL 是从应用程序中生成的URL,所以要做TOKEN验证;
  • 当用户访问需要生成跳转URL的页面时,首先生成随机token,并放入cookie
  • 应用程序在跳转前,判断token是否和cookie中的token一致,如果不一致,就判定为URL跳转攻击,并记录日志
  • 需要判断域名白名单后,才能跳转【可能存在被绕过风险】
  • 使用编号指定重定向的目标URL
  • 固定重定向的目标URL【评估、固定、不由外界指定】

 

 

 

 

 

 

 

[展开全文]

select

insert

updata

delete

库名、表名、字段名、字段内容

打破字面量(字符型、int型),尝试是否可改变SQL语句的构造

 

[展开全文]

是否可以通过WAF设备进行防护?

伪造跨站请求(SCRF)

防御方法:在cookei和表单中都随机一个

url redirect

 

万能语句:

 username='or  1=1

[展开全文]
  1. web作为攻击的突破口
  2. SQL注入:字面量部分被当做SQL代码执行
  3. SQL注入危害:拖库、提权
  4. SQL注入防御:参数化查询,数据与代码分离、过滤器:特殊字符、黑白名单
  5. XML注入: 用户能控制数据点输入、程序拼凑了数据
  6. XML注入防御:对语言本身的保留字段进行转移
  7. 代码注入:主要有不安全的函数或方法引起的。如eval()、import()等
  8. 系统命令执行:接收的用户输入中包含危险系统命令
  9. xss:本质是HTML注入,用户输入插入可执行脚本
  10. xss防御:过滤
  11. CSRF:伪装受信任用户的请求
[展开全文]

前端篡改、前端校验绕过、多步骤绕过

客户端提交数据不可信

在客户端限制用户输入是不现实的

到达后续阶段的用户不一定拥有相关权限

URL没有保密性可言

 越权漏洞

垂直权限

      低权限到高权限

       未授权访问

水平权限提升 

上下文相关的访问控制

修复建议

1、从session中获取关键字符,或对每个来自不信任的源直接对象引用都必须包含访问控制检查

2、使用一个中央程序组件检查访问控制,所有URL关联权限,并通过该组件检查每一个客户请求

3、在最后步骤中,重复校验前面步骤提交的所有认证数据。

4、记录每一个访问敏感数据或执行敏感数据操作的事件

 

 

 

 

 

 

 

 

 

 

[展开全文]

任意文件与路径遍历

提交文件目录地址酒吧目录的文件列表发给用户,造成目录遍历安全

关键字:

file_name=一个存在目录

就会返回目录下的文件

攻击:

避开“是否存在任何路径遍历序列”

不同的编码(url/unicode/双倍url)

使用斜线和反斜线的路径遍历序列

一个序列替换另一个序列“.../\”“...//”

 

包含应用需要的后缀(文件类型)或前缀(起始目录)

../../boot.ini%00.jpg 文件类型的00截断

指定的起始目录 filestore/../../etc/passwd

防御:

设置中间件,禁止目录遍历

对用户提交的文件名进行解码与规范,空字节

查看访问文件是否在指定目录中

阿里云的防御:

下载的文件地址保存到数据库中

用户提交对应的ID下载

下载前做权限判断

文件放在web无法直接访问的目录下

记录日志

 

文件上传漏洞

上传shell并且解析

绕过方式:

前端的js绕过

MIME类型检测

服务端目录检测 截断

文件类型检测 大小写 黑名单 特殊文件名 .htaccess攻击 解析漏洞

文件内容检测 幻数

解析攻击

防御:

上传文件目录是无法直接访问到的,不可解析脚本语言的目录

利用白名单来检查文件类型

随机重命名,不可带入任何可控参数

图片二次渲染

最新的webserver版本

 

文件包含漏洞

在PHP中常见

include(),include_once(),require(),require_once(),fopen()等函数

我先上传一个txt文件的php木马

然后用文件包含漏洞去包含这个txt

就会被php解析

防御:

白名单来检查文件类型

 

安全存储与传输

get提交密码 -》post提交

敏感信息加密传输或使用htps

敏感信息模糊化处理(张**,135****5555)

敏感文件加密处理

 

压缩目录与备份文件下载

zip.bak等文件直接下载,代码泄露

 

错误提示造成信息泄露

造成web的根路径泄露,数据库等信息泄露

防御:

给出统一的错误界面

 

框架漏洞

Struts2 任意命令执行漏洞   打补丁

spring表达式注入     关闭语言表达式功能,对特殊字符过滤

thinkphp代码执行      打补丁

 

webserver安全

禁止使用默认密码和弱密码

删除不必要的控制台与exp等路径

设置开关,禁止目录遍历

get与post

打补丁,升级版本

第三方编辑器:

越权,直接数入网址即可上传

FCK未授权访问与上传漏洞

 

安全错误配置

语言表达式关闭

开发模式关闭

中间件目录遍历关闭

版本更新

 

安全辅助  输入处理

校验字符编码

转换字符编码

输入校验  :

校验类型与校验对象:

校验控制字符

应用规格校验

校验字符数(SQL注入语句限制长度)

所有的参数都需要校验

 

二进制安全和空字节攻击

二进制:输入的字符原封不动的进行处理

空字节:%00截断

?p=123%)0<script></script>

 

软件安全开发--SDL

设计/开发/测试/部署

传输加密

参数绑定

 

Web安全开发总结

问题:

用户可以提交任意输入

防御:

处理用户的应用程序的数据和功能,防止非授权访问

信息泄露,爆路径

敏感信息要模糊化

记录攻击时间

能使用白名单就不要黑名单

数据和代码分离原则

木桶原则

 

代码执行--任意代码漏洞

命令执行--任意命令漏洞

文件操作--文件读写漏洞

数据库操作--SQL注入

数据显示--XSS

上传--上传漏洞

后台或API--安全认证绕过

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[展开全文]

会话管理:

会话ID嵌入URL

(会话ID由referer信息头泄露,造成伪装攻击)

无session验证

(越权)

会话未清除

(窃取cookie 先退出关闭会话)

Cookie secure

(cookie会通过窃听而失窃)

Session fixation

(会话固定攻击)

使用firebug查看cookie属性

登录前后sessionid未发生变化并且拼接在url中

错误的会话管理之防御:

会话ID嵌入url   会话ID保存在cookie中

无session验证  所有访问都要在会话中

会话未清除   注销,关闭浏览器超时清除会话

session fixation 认证之后要修改sessionid

 

重放攻击

两种 报文重放和cookie重放

cookie重放:

设置一个有效的sessionid就可以登录

防御:

新鲜性:一次失效的随机数保证url或者报文的新鲜性

时间戳:系统保持始终同步,设置一个合理的时间窗

 

暴力破解:

正向和反向破解

正向破解是一个账号使用多个密码来破解,过程可能会被系统锁定

反向破解是已知五次密码错误就锁定,我用四个密码去破解多个账号

 

验证码:

随机性不足  未一次失效

复杂度不足 校验码未刷新

本地生成(在html或者js中生成验证码)

 图形识别工作识别

异步提交(先校验验证码在校验密码,当验证码校验成功bp抓包直接破解密码就不用理会验证码)

未有失效时间

短信炸弹

 

账号枚举:

错误提示只显示用户名错误,可以指定账户

 

密码复杂校验

 

锁定:

正向锁定:一个用户匹配N个密码

反向锁定:一个密码匹配N个用户

 

防御:

保证验证码的随机性

失效时间

密码验证码一起提交,防止异步

一次失效

禁止本地生成

删除验证码后门(000永远都有效)

限制短信的频率

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[展开全文]

http消息头注入

在重定向或生成cookie等外部传参的参数输出http相应头所产生的安全隐患【参数中插入换行符】

生成任意cookie

%0D%0A 就是换行符

防御:

不直接使用url,是同编号的方式来指定

检查换行符

 

访问控制

前端篡改 校验绕过

防御:

客户侧提交的数据不可信

限制用户输入不现实

到达后续截断的用户不一定拥有相关权限

(修改密码的适合要提交旧密码)

url没有保密性

(不要妄图修改后台地址达到保密)

攻击方式

前端数据篡改:

篡改referer到达后续

篡改隐藏表单

篡改cookie

篡改URL参数(GET)

(修改url表示符达到越权访问)

篡改消息主题参数(POST)

前端校验绕过:禁用JS bp改包

绕过HTML表单内置输入确认机制

(修改前端参数)

基于脚本确认

(抓包修改后缀)

 

访问控制:

垂直权限提升: 未授权访问

完全不受保护

基于菜单防护

基于权限标识符

(admin=false/true)

静态文件未授权下载

平台配置错误

其他(基于位置)

水平权限提升:

基于标识符功能

(bp改包,可以看到不用工号的内容,

   过于信任客户侧修改参数

   防御:

添加筛选,只能获取session中的参数

上下文相关的访问控制:

(后端没有校验

客户提交手机号+新密码就成功

那么就可以修改其他手机号和密码

打破业务逻辑)

基于erferer

异步提交           :  直接访问下步骤url

                             最后提交数据篡改造成非法操作

                             功能逻辑被打破

防御(访问控制 越权):

不要太过于信任客户的侧数据,通过session来获取关键字

 对于 垂直权限提升:

 使用中央的越权限过滤器,对每个用户的url的请求来过滤,但是url要注意是否为篡改

在最后步骤中,要重新校验前面步骤提交的认证数据,就是异步控制机制还要防止越权校验

对于敏感操作要单独记录

赋予其他的防控措施

IP/MAC/双重校验/加密防篡改

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[展开全文]

会话清除:注销会话、关闭浏览器清除、超时清除会话固定攻击:登录前和登录后的session id没有改变,

 

重放攻击

客户端点击后,框架返回的URL携带生成的一个随机数,并且将随机数返回给业务系统,系统检查随机数是否一致,且只生效一次

反向暴力破解

若系统出现5次密码失效,则设置4次密码,无限匹配用户名

复杂度不足,短信验证码只有4次

验证码本地生成较少,短信较多,有客户端生成

被图形工具识别,北京为春色的验证码

异步提交:先提交验证码,在提交用户名/密码

短信炸弹:点击一个按钮不断发短信,使用burpreaperter

账号枚举:有admin用户,无root用户

密码复杂度校验要放在服务端

验证码未一次失效,上一次验证码仍有效

密码复杂度校验在客户端校验可以使用burp绕过 

 

[展开全文]

授课教师

产品经理

课程特色

视频(4)
下载资料(1)

学员动态