网络攻防学什么语言 最稳定安全的编程语言( 三 )


当正确的使用了 GET 和 POST 请求之后 。剩下的就是在非 GET 方式的请求中增加随机数 。这个大概有三种方式来进行:
为每个用户生成一个唯一的 cookie token 。所有表单都包含同一个伪随机值 。这种方案最简单 。因为攻击者不能获得第三方的 cookie(理论上) 。所以表单中的数据也就构造失败 。但是由于用户的 cookie 很容易由于网站的 XSS 漏洞而被盗取 。所以这个方案必须要在没有 XSS 的情况下才安全 。
每个 POST 请求使用验证码 。这个方案算是比较完美的 。但是需要用户多次输入验证码 。用户体验比较差 。所以不适合在业务中大量运用 。
渲染表单的时候 。为每一个表单包含一个 csrfToken 。提交表单的时候 。带上 csrfToken 。然后在后端做 csrfToken 验证 。
CSRF 的防御可以根据应用场景的不同自行选择 。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量 。但是这种工作量是值得的 。毕竟用户隐私以及财产安全是产品最基础的根本 。
SQL 注入SQL 注入漏洞(SQL Injection)是 Web 开发中最常见的一种安全漏洞 。可以用它来从数据库获取敏感信息 。或者利用数据库的特性执行添加用户 。导出文件等一系列恶意操作 。甚至有可能获取数据库乃至系统用户最高权限 。
而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入 。使攻击者成功的向服务器提交恶意的 SQL 查询代码 。程序在接收后错误的将攻击者的输入作为查询语句的一部分执行 。导致原始的查询逻辑被改变 。额外的执行了攻击者精心构造的恶意代码 。
很多 Web 开发者没有意识到 SQL 查询是可以被篡改的 。从而把 SQL 查询当作可信任的命令 。殊不知 。SQL 查询是可以绕开访问控制 。从而绕过身份验证和权限检查的 。更有甚者 。有可能通过 SQL 查询去运行主机系统级的命令 。
SQL 注入原理下面将通过一些真实的例子来详细讲解 SQL 注入的方式的原理 。
考虑以下简单的管理员登录表单:
1 2 3 4 5<form action="/login" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value=https://www.wangchuang8.com/"登陆" />

后端的 SQL 语句可能是如下这样的:
1 2 3 4 5 6 7let querySQL = ` SELECT * FROM user WHERE username='${username}' AND psw='${password}' `; // 接下来就是执行 sql 语句...目的就是来验证用户名和密码是不是正确 。按理说乍一看上面的 SQL 语句也没什么毛病 。确实是能够达到我们的目的 。可是你只是站在用户会老老实实按照你的设计来输入的角度来看问题 。如果有一个恶意攻击者输入的用户名是 zoumiaojiang’ OR 1 = 1 – 。密码随意输入 。就可以直接登入系统了 。WFT!
冷静下来思考一下 。我们之前预想的真实 SQL 语句是:
1SELECT * FROM user WHERE username='zoumiaojiang' AND psw='mypassword'可以恶意攻击者的奇怪用户名将你的 SQL 语句变成了如下形式:
1SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1 --' AND psw='xxxx'在 SQL 中 。– 是注释后面的内容的意思 。所以查询语句就变成了:
1SELECT * FROM user WHERE username='zoumiaojiang' OR 1 = 1这条 SQL 语句的查询条件永远为真 。所以意思就是恶意攻击者不用我的密码 。就可以登录进我的账号 。然后可以在里面为所欲为 。然而这还只是最简单的注入 。牛逼的 SQL 注入高手甚至可以通过 SQL 查询去运行主机系统级的命令 。将你主机里的内容一览无余 。这里我也没有这个能力讲解的太深入 。毕竟不是专业研究这类攻击的 。但是通过以上的例子 。已经了解了 SQL 注入的原理 。我们基本已经能找到防御 SQL 注入的方案了 。
如何预防 SQL 注入防止 SQL 注入主要是不能允许用户输入的内容影响正常的 SQL 语句的逻辑 。当用户的输入的信息将要用来拼接 SQL 语句的话 。我们应该永远选择不相信 。任何内容都必须进行转义过滤 。当然做到这个还是不够的 。下面列出防御 SQL 注入的几点注意事项:
严格限制Web应用的数据库的操作权限 。给此用户提供仅仅能够满足其工作的最低权限 。从而最大限度的减少注入攻击对数据库的危害
后端代码检查输入的数据是否符合预期 。严格限制变量的类型 。例如使用正则表达式进行一些匹配处理 。

推荐阅读