标签：代码 漏洞 cookie SQL 攻击者 页面 注入

代码注入

代码注入是利用计算机的错误，这种错误是由处理无效数据引起的。成功的代码注入的结果可能是灾难性的（数据泄露、篡改数据等）

一、SQL注入

SQL注入利用SQL的语言来注入恶意命令，这些命令可以读取或修改数据库，或损害原始查询的含义。

1、错误构造的SQL语言

这种形式的注入依赖于一个实事，即SQL语言既包含SQL语言使用的数据，也包括控制SQL语言执行方式的命令。

SELECT * FROM users WHERE name = '' OR '1'='1';

2、SQL盲注

当SQL输入的结果不被攻击者不可见时，可使用SQL盲注。即便存在此漏洞的页面可能不显示数据的页面，但会根据注入得到的不同结果进行判断，从而构建起结构。

3、二阶SQL注入

当提交的值包含存储而不是立即执行的恶意命令时，就会发生二阶SQL注入。自动化的Web安全扫描程序不容易检测到这种类型的SQL注入，可能需要人工审核检测。

4、预防措施

1）严格区分并限制普通用户和管理员用户权限，防止管理员能够通过web网站进行相关数据查询；

2）采用参数化语句：将需要执行的SQL语句设置成一定的参数并限制参数运行方式。

3）使用存储过程：根据业务需要对数据存储过程进行限制；

4）使用SQL自带的安全参数（预编译）：例如SQL Server服务的sqlparameters集合；Mysql Server中的Mysqloarameters；

5）多层次验证：采用多种方式混合进行SQL语句验证，例如在PHP启用POD，在SQL数据库在启用Parameters；

6）在系统上前使用专业的漏洞扫描工具进行验证，例如neuss；

7）账号混淆：修改默认管理员的用户名称为其他，再将普通用户名修改成原理员名称，通过混淆方式真假难辨；

二、跨站脚本（XSS）

是一种恶意代码注入攻击，攻击者可攻击Web服务器并将自己的恶意代码注入到Web页面中，当其他人员访问该Web页面时将恶意代码传送至其他人员客户端。

1、非持久性（或反射）

1）非持久性跨站脚本攻击场景：XSS窃取cookie

1. 客户（A）经常访问一个大型网站，该网站是由企业（B）进行管理。大型网站允许客户A访问自己的数据，如搜索记录、信用卡等信息。当用户访问网站上时浏览器会保留一个授权Cookie，用于记录并表明用户已经正常登录；

2. 攻击者（C）在企业（B）的网站上发现了一个非持久性（或反射性）漏洞。

3. 攻击者（C）根据这个漏洞的实现方式编写了一个steal_cookie.js文件，将其通过URL关联的方式隐藏成看似正常的URL连接（实际恶意URL连接），并通过恶意邮件（如咖啡优惠卷）发送给客户（A）；

4. 客户A因为“小便宜”心理点击了这个URL连接，那么这个URL连接在运行起来时会调用steal_cookie.js，通过用户看不到的方式自行获取用户浏览器中的cookie文件并将其发送给攻击者（C）

5. 攻击者（C）在获取到客户（A）的cookie文件之后，即可通过该cookie文件伪装成客户（A）查询相关信息，甚至可以进一步窃取管理员权限；

PS：我记得在某一个美剧出现过相应的镜头。但是我忘记是那个了。唉~

2、持久型（或存储）

1）持久型跨站脚本攻击场景：XSS窃取cookie

1. 攻击者（C）通过客户（A）的账户在企业（B）的网站上，重新发现了一个XSS漏洞，这个漏洞在于一个留言板：如果一个人在留言板发表评论，网站将显示任何输入的内容。如果评论文本中包含HTML标签，它们将被添加到网页的源代码中并且这个标签是可以在页面加载时运行的。

2. 攻击者（C）通过客户（A）的账户在留言板上面编写了一段话并包含HTML标签（该标签可以运行steal_cookie.js脚本）；

3. 当任何人访问这个留言板时都会自动加载并运行steal_cookie.js脚本，并将其发送至攻击者（C）；

3、非持久性与持久型的区别

持久型是存在页面中并且随着页面的加载而加载，它会随着页面的存在而存在；非持久性则是需要使用人（或攻击者）自行运行，不会保存在页面；

4、DOM跨站脚本攻击

通过修改原始的客户端代码，受害者浏览器的DOM环境发生改变，导致恶意有效载荷在客户端被执行。但是这个攻击未对Web页面进行修改。

5、预防措施

1）HTML转义： 将用户输入的内容进行转义，转义后确保用户输入的在浏览器作为文本显示，而不是作为相关代码解析；例如HTML escapeHTML

2）白名单：因为不是只有HTML存在白名单，例如JavaScript API都可能绕过相关检测机制，因此通过采用白名单的方式保证相关运行的代码是我们允许运行的；

3）输入验证：在用户提交相关数据时进行验证，但是输入验证在使用可能引入不确定性问题（如乱码），因此输入验证需要谨慎使用。但是在一些特定格式下的内容（如邮箱、电话等）是推荐的；

4）纯前端渲染：我们会明确告诉浏览器，下面要设置的内容是文本、还是属性、还是样式等等。让浏览器不会被轻易的欺骗，执行预期之外的代码；

5）内容安全策略（Content Security Policy，CSP）：采用严格的内容安全策略（CSP）可以防范XSS。它是一个额外的安全层，用于检测并削弱某些特定类型的攻击；

6）HTTP-only Cookie：HTTP-Only是包含在Set-cookie http相应头文件中，生成cookie时使用Httponly标志，只允许服务端对cookie文件进行修改，这样就可以减少恶意的cookie窃取；

7）限制输入长度：总会安全一点，聊胜于无。

8）安全防护设备：有钱直接来一套。O(∩_∩)O

三、模板引擎注入（Server Side Template Injection，SSTI）

Web应用程序广泛使用模板引擎（Template Injection，例如freemarker、twig）让其通过网页活电子邮件呈现动态内容。但是在模板引擎中存在异常，导致不安全地嵌入式用户输入进而引发模板引擎注入，但是这个容易被误认为跨站脚本（XSS）或者未被识别。

四、动态评估漏洞

当攻击者可以控制输入到函数中的全部或部分输入字符串时，就会出现注入漏洞。但是这种类型的漏洞并非PHP所独有。

五、文件包含漏洞

文件包含漏洞是一种Web漏洞，最长发现它会影响依赖于脚本运行时的Web应用程序。当应用程序使用攻击者控制的变量构建成可知性代码的路径，以使攻击者能够控制在运行时执行哪个文件。

1）远程文件包含（RFI）

指能够包含远程服务器上的文件并执行。

2）本地文件包含（LFI）

指的是能打开本地文件的漏洞。

六、参考连接

前端安全系列（一）：如何防止XSS攻击？ - 美团技术团队 (meituan.com)

内容安全策略 ( CSP ) - HTTP | MDN (mozilla.org)

服务器端模板注入|波特斯威格研究 (portswigger.net)

动态评估漏洞 Full Disclosure: Dynamic Evaluation Vulnerabilities in PHP applications (seclists.org)

详解模板注入漏洞（上） (qq.com)

详解模板注入漏洞（下） (qq.com)

 

标签：代码,漏洞,cookie,SQL,攻击者,页面,注入
From： https://www.cnblogs.com/ColoFly/p/16707896.html