解决DVWA配置报错

之前在ubantu下部署DVWA学习Web漏洞的时候碰到了访问DVWA页面404错误、mysql 1045(28000)错误两个问题，今天有时间写一下解决办法

1.PHP的配置问题（apache2.conf）

   默认路径确实是/var/www 但是，在此目录下的php文件时无法打开的，提示404错误，无法找到路径下文件

                 需要把文件放在/var/www/html下才能找到，但是路径是不需要加/html的

2.mysql 1045（28000）错误解决，需要重置数据库root用户的密码

   1）sudo /etc/init.d/mysql stop      暂停数据库服务

   2）sudo /usr/bin/mysqld_safe --skip-grant-tables --skip-networking &      跳过密码验证（可能会报错）

             2.1） 如果出现2018-09-08T11:50:44.870970Z mysqld_safe Logging to '/var/log/mysql/error.log'.
                           2018-09-08T11:50:44.872874Z mysqld_safe Logging to '/var/log/mysql/error.log'.
                           2018-09-08T11:50:44.874547Z mysqld_safe Directory '/var/run/mysqld' for UNIX socket file don't exists.
                       
                         这种错误则执行2.2）
             
             2.2）mkdir -p /var/run/mysqld                  自己创建这个目录
                  chown mysql:mysql /var/run/mysqld         更改文件的所属用户


   3） 2.2执行完后，终端不要关闭，打开一个新的终端 ， mysql -u root  登录进去

       执行  update user set authentication_string=PASSWORD("这里输入你要改的密码") where User='root'; #更改密码
       执行  update user set plugin="mysql_native_password"; #如果没这一行可能也会报一个错误，因此需要运行这一行
       执行  flush privileges; #更新所有操作权限
       执行  quit              #退出


   4） 重启验证
       sudo /etc/init.d/mysql stop
       sudo /etc/init.d/mysql start 
       mysql -u root -p

          输入正确的密码后进入数据库，原本的那个终端可能会卡死，（我直接关闭了）

$至此DVWA能正确创建数据库了，注意DVWA的config.inc.php文件的配置，账号密码需要和mysql的一致，然后自动跳转到DVWA的login页面
A1:2017 – 注入
将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS 注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预 期命令或访问数据。

防御思路：
--------------官方文档防御思路总述---------------
防止注入漏洞需要将数据与命令语句、查询语句分隔开来。
》 最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。
》 注意：当参数化时，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即执行或exec()的恶意数据。
》 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。
》 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和类似的库提供了这样的转义例程。
》 注意：SQL结构，比如：表名、列名等无法转义，因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。
》 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
SQL注入：
①PreparedStatement（参数化查询）
采用JDBC的预编译语句集，它内置了处理SQL注入的能力，只要使用它的setXXX方法传值即可。
使用好处：
(1).代码的可读性和可维护性.
(2).PreparedStatement尽最大可能提高性能.
(3).最重要的一点是极大地提高了安全性.
原理：
sql注入只对sql语句的准备(编译)过程有破坏作用
而PreparedStatement已经准备好了,执行阶段只是把输入串作为数据处理,
而不再对sql语句进行解析,准备,因此也就防范了sql注入问题.
②过滤sql语句保留字
使用正则表达式来过滤一些sql关键字，如or、where等
③使用存储过程
存储过程可避免SQL注入，但也可能会存在注入问题，因此应该尽量避免在存储过程中使用动态的SQL语句。如果无法避免，则应该使用严格的输入过滤或者是编码函数来处理用户的输入数据
④检查数据类型
使用is_numeric()，, ctype_digit()等过滤函数检查数据类型
⑤过滤特殊字符
使用addslashes()、mysql_real_escape_string()、mysql_escape_string()等函数尝试过滤特殊字符，但是防御能力有限
⑥使用白名单
一般很难做到将业务所需的字段或者字符全部完善地加入白名单，不太现实

NoSQL注入：
从注入原理上看NoSQL注入的思路和SQL注入类似，但是NoSQL 数据库（主流的有MongoDB、Cassandra 和 Redis）使用不同的查询语言。
NoSQL攻击主要有:
重言式: 利用$ne操作（不相等）等绕过验证联合查询:利用$or等其他运算符进行攻击，从而导致整个语句判定出错，进行非法的数据获取。
JavaScript 注入:传递不干净的用户输入到这些查询中可以注入任意JavaScript 代码，这会导致非法的数据获取或篡改。
背负式查询:攻击者通过利用转义特定字符（比如像回车和换行之类的结束符）插入由数据库额外执行的查询，这样就可以执行任意代码了。
跨域违规: HTTP REST APIs 是 NoSQL 数据库中的一个流行模块，然而，它们引入了一类新的漏洞，它甚至能让攻击者从其他域攻击数据库。在跨域攻击中，攻击者利用合法用户和他们的网页浏览器执行有害的操作

从攻击类型来看，NoSQL注入所利用的语言没有限制，防御时需要根据具体使用的数据库和语言，根据其特性对不可信的输入（借鉴SQL注入的防御思想），对其限制。

OS注入：
①使用系统库函数调用
如果可能，使用库调用而不是外部进程来创建所需功能。

②使用沙箱/沙盒
让暴露在外界的程序执行在具有安全边界的模拟环境中

③使用安全的库或框架
使用 ESAPI 编码控件http://www.owasp.org/index.php/ESAPI或类似的工具、库 或框架可以降低一般程序员写出风险代码的几率

④输入验证
输入验证仍然是最简单有效的防御方法，检查输入的内容包括但不限于长度、输入类型、语法。检查操作系统命令字符串时，可以严格使用白名单策略。并且在需要输出时，要加以适当的输出编码转义。

⑤程序运行在所需的最低权限下

LDAP注入：
① 完善，格式化查询语句，防止被修改
② 使用已有的安全框架
③ 将需要转义的字符进行转义

-----------------个人防御思路分类总结------------------
A2:2017 – 失效的身份认证
通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌， 或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。

防御思路：

--------------官方文档防御思路总述---------------
》 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。
》 不要使用发送或部署默认的凭证，特别是管理员用户。
》 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码” 列表。
》 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的5.1.1章节-记住秘密，或其他现代的基于证据的密码策略相一致。
》 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。
》 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。
》 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
弱密码：
① 不要使用自带的默认密码
② 密码长度8位以上，数字，字母大小写，特殊字符混合
③ 密码不和个人信息相关连，具有随机性
④ 定期更换重要账户的密码
密码爆破：
① 以强密码为前提，不使用已经存在漏洞的加密方式
② 不同环境不同密码，可以防御统计分析爆破和撞库
③ 多次尝试错误，需要合理设置锁定机制
④ 使用高强度验证码
密码找回：
① 必须使用强密码找回凭证，不可以直接从客户端获取，不能泄露在任意位置
② 建议设置凭证时使用随机信息，不使用真实信息
③ 检查密码找回逻辑，不能发生越权修改。
COOKIE伪造：
① 不要点击恶意链接
② cookie设置要加盐（时间+IP+随机串等等形式）
③ 验证cookie与当前信息是否对应
越权：
① 用户登录后，将用户的个人信息存入session中
② 进行敏感操作时要再次进行身份校验
③ 用户退出之后，要清理session信息
会话劫持：
① 加密，且加密信息安全不可猜测。用户每次登陆重置session
② 要有会话劫持检测
③ 设置HttpOnly，关闭透明化Session ID，User-Agent验证，进行Token校验
④ session过期时间减短
验证码破解：
① 验证码不能仅仅在客户端校验
② 验证码不能泄露于其他用户能够获取的地方
③ 验证码要有时效性
④ 验证码复杂性和用户体验要有权衡

-----------------个人防御思路分类总结------------------
A3:2017 – 敏感信息泄露
许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗数据和PII数据。攻击者可 以通过窃取或修改未加密的数据来实施信用卡诈骗、身份盗窃或其他犯罪行为。未加密的敏感数据 容易受到破坏，因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、存储的数据 以及浏览器的交互数据。

防御思路：
--------------官方文档防御思路总述---------------
对一些需要加密的敏感数据，应该起码做到以下几点：
》 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
》 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。
》 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
》 确保存储的所有敏感数据被加密。
》 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。
》 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS ）。
》 禁止缓存对包含敏感数据的响应。
》 确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受范围。
》 单独验证每个安全配置项的有效性。
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
① 根据自身环境的特点找到可能存在的敏感信息泄露点
② 敏感信息不能通过明文的方式存储，传输和显示，必须选择安全算法加密
③ 敏感信息不应直接通过URL的方式传输
④ 检查如phpinfo,xxx.swp等其他可能遗留的页面
⑤ 其他参考官方防御思路
-----------------个人防御思路分类总结------------------

A4:2017 – XML外部实体（XXE）
许多较早的或配置错误的XML处理器评估了XML文件中的外部实体引用。攻击者可以利用外部实体窃 取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻 击。

防御思路：
--------------官方文档防御思路总述---------------
》 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。
》 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。
》 参考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。
》 在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。
》 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。
》 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（ WAF ）来检测、监控和防止XXE攻击。
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
1.禁用xml外部实体
PHP：
libxml_disable_entity_loader(true);

JAVA:
DocumentBuilderFactory dbf =DocumentBuilderFactory.newInstance();
dbf.setExpandEntityReferences(false);

Python：
from lxml import etree
xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))

2.过滤xml外部实体的关键字：
过滤, , SYSTEM 等

注意：举个例子，XXE的利用其实和php版本没有关系，但是与xmllib库有关系，xmllib2.9.0以后，是默认不解析外部实体的。所以防御思路应该是检查各应用底层的xml解析库。
-----------------个人防御思路分类总结------------------

A5:2017 – 失效的访问控制
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数 据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。

防御思路：
--------------官方文档防御思路总述---------------
访问控制只有在受信服务器端代码或没有服务器的 API 中有效，
这样这样攻击者才无法修改访问控制检查或元数据。
》 除公有资源外，默认情况下拒绝访问。
》 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。
》 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。
》 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。
》 禁用 Web服务器目录列表，并确保文件元数据（如：git）不存在于 Web的根目录中。
》 记录失败的访问控制，并在适当时向管理员告警（如：重复故障）。
》 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
》 当用户注销后，服务器上的JWT令牌应失效。开发人员和 QA人员应包括功能访问控制单元和集成测试人员。
--------------官方文档防御思路总述---------------

-----------------个人防御思路分类总结------------------
三种访问控制模型：
基于角色的访问控制（RBAC） 基于角色
自由访问控制（DAC） 基于授权
强访问控制（MAC） 基于敏感度

访问控制验证要求：
① 验证最小特权的原则：用户应仅能够访问函数、数据文件、URL、控制器、服务和其他资源，它们处理特定的授权，它们使应用程序免受欺骗和提权。
② 验证对敏感记录的访问是否实施了保护措施，这样只有授权的对象或数据才允许访问（例如：防止用户篡改参数或更改其它用户账户）
③ 验证目录遍历是禁用的，除非故意为之。此外应用程序不应允许发现或泄露文件或目录元数据，例如：Thumbs.db、.DS_Store、.git或.svn
④ 验证访问控制是否以安全的方式显示失败处理。
⑤ 验证表示层访问控制规则是否在服务器端强制执行。
⑥ 验证访问控制使用的所有用户和数据属性、策略信息不能被终端用户操纵，除非特别授权。
⑦ 验证是否存在集中化机制（包括调用外部授权服务的库），以保护对每种受保护资源的访问。
⑧ 验证是否可以记录所有访问控制决定，并记录所有失败的决定。