文章目录
指标挖掘
- 多IP登陆同一账号
- 同IP登录多个账号
- 检测到用户尝试输入攻击性字符串
- 多次输入账号密码错误（低级）
- 离职人员登录账号
- 账号异常登录（登录ip与账号责任人ip不符）（低级）
- 用户密码相似度达到%?（低级）
- 多个组件使用相同密码
- 多次输错密码禁用ip
Web安全
核心防御机制
Web采用的防御机制主要有：
- 处理用户访问应用程序的数据与功能，防止用户获得未授权访问
三层关联机制：身份验证，会话管理，访问控制- 获取未授权数据（分权，分配用户访问权限、操作权限和数据权限）
- 破解令牌（更安全的令牌）
- 密码简单（不用通用密码）
- 处理用户对应用程序功能的输入，防止错误输入造成不良行为
- SQL注入
- 跨站伪造
- 长度限制
- 防范攻击者，确保应用程序在成为直接攻击目标时能够正常运转，并采取适当的防御与攻击措施挫败攻击者
- 操作日志
- 登录日志，密码修改
- 关键信息编辑、删除
- 没有权限的访问
- 包含攻击字符串
主要能够根据其防御机制，在防御的同时进行预警，挖掘指标
- 操作日志
HTTP
超文本传输协议，基于TCP/IP的应用层协议，定义了数据如何在万维网进行通信，消息体可选，消息头必须
用户访问某网站时浏览器响应步骤
- 解析用户输入的地址（协议名、主机名、端口、路径）
- 将解析结果结合本机信息，封装一个HTTP数据包
- 使用TCP协议连接到主机的指定端口，并发送数据包
- 等待相应，解析返回数据并展示
消息头
请求头：
GET /simple.htm HTTP/1.1<CR>
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR>
Accept-Language: zh-cn<CR>
Accept-Encoding: gzip, deflate<CR>
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR>
Host: localhost:8080<CR>
Connection: Keep-Alive<CR>
<CR>
响应头：
HTTP/1.1 200 OK<CR>
Server: Microsoft-IIS/5.1<CR>
X-Powered-By: ASP.NET<CR>
Date: Fri, 03 Mar 2006 06:34:03 GMT<CR>
Content-Type: text/html<CR>
Accept-Ranges: bytes<CR>
Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR>
ETag: "5ca4f75b8c3ec61:9ee"<CR>
Content-Length: 37<CR>
<CR>
<html><body>hello world</body></html>
HTTP方法
- GET：获取资源，参数在URL中
- POST：执行操作，参数应在消息体中
- HEAD：与GET类似，返回中没有消息体，用于检查目标资源是否存在
- PUT：上传消息体包含的文件（可进行攻击）
GET和POST的区别
https://www.cnblogs.com/logsharing/p/8448446.html 这个写的很有意思
- 两者都是TCP链接，本质上没有不同，POST可在URL中加参数，GET也可把参数放在请求体中
- HTTP为了区分消息请求的类型，约定了GET和POST具有以下区别：
- GET在浏览器中回退是无害的，而POST会再次提交请求
- GET产生的地址可以被BookMark，POST不行
- GET请求会被浏览器主动Cache，POST需要手动设置
- GET请求只能进行url编码，POST支持多种编码格式
- GET请求参数会被完整保存在历史记录中，POST不会
- GET请求在URL传递的参数长度受限，POST不会（大多浏览器限制2K，大多服务器最多处理64K）
- GET更不安全，因为参数暴露而无法传递敏感信息
- GET参数在URL中，POST在消息体中
- GET产生一个TCP数据包（header和body一起发），POST产生两个数据包（先发header，响应100，然后发body，再响应200，相当于先握手）
URL
统一资源定位符，常用格式：
protocol://hostname:port/[path/]file[?param=value]
找到具体的文件资源
REST
设计接口时，不用动词只用名词，动作用HTTP方法表示
增加一个朋友，uri: generalcode.cn/v1/friends 接口类型：POST
删除一个朋友，uri: generalcode.cn/va/friends 接口类型：DELETE
修改一个朋友，uri: generalcode.cn/va/friends 接口类型：PUT
查找朋友，uri: generalcode.cn/va/friends 接口类型：GET
反例：generalcode.cn/va/deleteFriends
会话
Cookie
HTTP是无状态的，无法判断用户身份，cookie是一个key-value，如果服务器需要记录用户状态，就使用Set-Cookie响应消息头发布cookie给用户浏览器，然后用户的浏览器将cookie保存，再次浏览时自动将cookie添加到给服务器的请求头中，就像公司的身份卡
浏览器端的数据存储技术，作为服务端开发者我们是需要借助浏览器实现cookie会话的，落实到实际，java可以通过HttpServletRequest接口来访问浏览器请求中的cookies，或者通过HttpServletRespose接口帮助浏览器进行setCookie，将cookie存储到用户本地，通过这一存一取就可以获取用户状态和我们自定义的一些属性，设置过期时间就是持久级别，否则是会话级别
Session
Session基于Cookie，抛弃冗余属性，只用一个唯一的id进行用户标识，此id通常是Name为JSESSIONID的一个cookie
当浏览器第一次访问服务器时，服务器创建Session并将SessionID通过Cookie带给浏览器保存在客户端，同时服务器根据业务逻辑保存相应的客户端信息保存在session中；客户端再访问时上传Cookie，服务器得到Cookie后获取里面的SessionID，来维持状态。
禁用cookie session还能用吗
可以，session可以通过URL解码获得
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UBsHnA60-1652604933541)(https://note.youdao.com/yws/res/4/WEBRESOURCE6b20b2d0dc6f86a5977b5ce10e0e5d54)]
状态码
详见文档：HTTP相关：http://note.youdao.com/noteshare?id=ab6c257e46ca702941be7264291ed7d5&sub=63067CBFFAFA44BDAFACBAE29FC8FAF1
HTTPS
HTTP+SSL/TLS，HTTP与TCP间加了一层SSL层
之前的HTTP在TCP三次握手后发送数据，数据明文传输且没有验证机制，容易被黑客截获然后篡改甚至冒充返回，需要加密传输数据并验证服务端身份
- 对称加密：用同一密钥进行加密解密，密钥交接不太安全且需要维护大量密钥
- 非对称加密：客户端用服务器公开的公钥加密数据，服务器用自己的私钥解密，验证对方身份的同时安全性也高
具体详见 https://note.youdao.com/s/VGZ5fOPk
WEB功能
Ajax核心技术为XMLHttpRequest（待学习）
同源策略：浏览器对javascript的限制，协议、域名、端口都相同才能访问，有一个不同就会产生跨域而请求失败（TODO）跨域问题
WEB编码
一个东西需要编码，说明本身不适合传输，如size过大、包含敏感数据、特殊字符等
计算机编码详情见https://note.youdao.com/s/TfrGRuWD
- URL编码：一是URL只支持英文数字，二是HTTP传值是?key=value&这种，如果value中包含=或&这种字符就容易引起歧义，所以URL会把特殊字符、中文变成%开头的ASCII码以保证安全传输，部分浏览器的地址栏会自动解码
- TODO
攻击数据存储区
注入解释型语言
基于解释型语言的执行方式，产生了代码注入的漏洞（Java的反序列化漏洞TODO）
注入SQL
SQL注入的两个条件：
- 我们传递给后端的参数是可以控制的
- 参数内容会被带入到数据库查询
sql绕过admin' --，' or 1 = 1 --
select * from tb_user where username = 'admin' -- and password = '123';
-- 为注释
SQL注入防御：
-
预编译：
INSERT INTO MyGuests (firstname, lastname, email) VALUES(?, ?, ?)- mybatis使用
#{}代表将参数作为字符串传入，代表占位符；${}仅代表参数替换，可以进行注入 SELECT * FROM order WHERE name like '%#{name}%' //会报语法错
SELECT * FROM order WHERE name like '%${name}%' //可以运行
SELECT * FROM order WHERE name like concat('%',#{name}, '%') //正确的写法
- mybatis使用
-
特殊字符过滤
SQL注入是否死透
- 预编译不能解决所有SQL注入：比如表名/列名/排序动态传入的场景，原因是这些地方不能预编译，因此很多人还是直接拼接的
- 可以预编译的地方也有可能出现问题：注入一般爆发在LIKE语句/IN语句中，因为这两个地方的预编译写法都有些特殊，很多开发者懒得去搞，就直接拼接了
- 在SQL语句的写法上，直接拼接比预编译简单太多了，没有接触过信息安全的初学者写出来的代码很大可能存在漏洞
- 有太多有漏洞的老代码来不及或不能换上预编译
随着框架的完善和推广，sql注入会越来越难
XSS 攻击
分为反射型、保存型和基于DOM型
-
反射型XSS的被攻击对象一般是攻击者去寻找的，就比如说：一个攻击者想盗取A的QQ号，那么攻击者就可以将一个含有反射型XSS的URL链接给A，此时我们可以看出，需要将特定的URL，注意是特定的URL给A，当A点击进入链接时，就受到XSS攻击，所以这种攻击范围不是特别的广。
-
存储型XSS是广撒网的方式或者指定的方式，就是攻击者将存储型XSS放在一些有XSS漏洞的网站上，只要有用户访问这个链接就会中招，而攻击者也可以寻找被攻击对象，比如说上面的例子，所以我们可以看出，存储型XSS的危害性更大，范围更广，可以不需要寻找被攻击对象，只要存储型XSS在服务器上就能实施攻击。
-
DOM型XSS的被攻击对象其实和反射型XSS被攻击对象差不多，就是给攻击对象放送URL。
-
反射型XSS的脚本被解析的地方是浏览器，而存储型XSS的脚本被解析的地方是服务器，DOM型XSS也是浏览器，所以DOM型又叫DOM反射型XSS。但是反射型XSS需要联网，而DOM型不需要
反射型
- 用户登录应用程序，得到一个包含会话令牌的cookie
- 攻击者向用户提交一个URL（请求某站点并在url中携带用户cookie，可通过dom获取），例如提交一个一段嵌入js（
http://ip:port/url?mesg=attackUrl?cookie）（攻击者需要诱使用户点击该链接进行url跳转） - 用户请求该url
- 服务器响应用户请求
- 攻击者的js代码在用户的浏览器中执行
- 攻击者劫持会话
注意，攻击者无法通过他们自己的url获取用户信息，这是因为浏览器的同源策略，只有发布该cookie的站点可访问这些cookie
总结：不保存注入信息，小到在不过滤关键字的网站的输入框内直接注入标签，大到诱导用户点击链接进行信息获取
参考：https://blog.csdn.net/guanshanyue96/article/details/90215428
保存型
常见是保存一段恶意代码在留言板，只要用户加载留言板就会加载js，常见的比如阿波罗的发布框进行注入
基于DOM
我的评价是，不如反射型和保存型
具体需要到《XSS攻击》篇进行详细了解
扫一扫
551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
