对于很多公司来说,直到发生安全漏洞后,网络安全最佳实践才成为优先事项.
Web开发安全问题,其实对很多程序员来说都是很模糊的.
应对 Web 安全威胁的有效方法必须是主动的.
下面说一下10种常见且重要的Web安全陷阱的认识和解决方法.
身份验证(Authentication)和身份授权(Authorization)
程序员经常对身份授权和身份验证之间的区别表示困惑.对这两个术语使用会增加它们的"朦胧感".
区别:
- 认证：验证用户是否是或者或至少看起来是"人".
- 授权：授予用户对特定资源的访问权限或执行特定操作的权限。
换句话说,身份验证是知道实体是谁,而授权是给定实体可以做什么.考虑到这一点,就探讨 10 种常见的互联网漏洞问题.
注入缺陷(Injection Flaws)
注入缺陷是经典的由于过滤不受信任的输入的失败造成的.当我们将未过滤的数据传递到SQL服务器（SQL 注入）/浏览器（通过跨站脚本）/LDAP 服务器（LDAP 注入）或其他任何地方时,可能会发生注入缺陷.这里的问题是攻击者可以注入命令来劫持客户端的浏览器,从而导致数据丢失损坏或勒索.
应用程序应当从不受信任的来源接收的任何内容且必须进行过滤,最好是根据白名单进行过滤.不建议为此使用黑名单,因为很难正确配置.黑名单也被认为很容易被黑客绕过.
预防
防止注入只是"简单"的过滤用户的输入,并考虑哪些用户是可以信任的.过滤是一项相当艰巨的任务,因为我们需要处理所有输入,除非它毫无疑问是可信的.
如果我们在一个有1000个输入的系统中过滤999个输入,仍然有一个字段可以成为导致我们系统崩溃的致命弱点.
由于过滤很难正确，因此建议使用腾讯云T-Sec Web应用防火墙.是非常有效的.
身份验证中断(Broken Authentication)
在身份验证中断期间可能出现的问题不一定来自同一种原因.有无数可能的陷阱,如:
- URL可能包含会话ID，并在referer头中泄漏
- 密码可能在存储或传输过程中未加密
- 会话ID可能是可扫描出来的,这使得获得未经授权的访问变的太容易了
- 使用HTTP(没有使用SSL)等,则可能发生会话劫持
预防
使用成熟的框架编写代码.如果您编写自己的代码,请要非常谨慎的编写任何一行代码.并就可能出现的潜在问题进行反省.
跨站点脚本攻击 （XSS）
攻击者将输入js标记的代码发送到网站.当此输入在未经处理的情况下返回给用户时,用户的浏览器将执行它.这是一个相当普遍的过滤失败,(本质上是注射缺陷).例如:在页面加载时,脚本将运行并用于某些权限的cookie发送给攻击者.
预防
将一些HTML标签转为实体.如:<script>转为<script>
不安全的直接对象引用
这是一个典型的案例,即信任用户的输入,并通过继承这个想法产生的安全漏洞.并付出代价.
直接引用对象意味着内部对象（例如，文件或数据库密钥）暴露给用户,更容易受到攻击.
攻击者可以提供此引用,如果身份授权未被强制执行或被破坏,攻击者就会进入后台.
例如:该代码有一个模块,可以读取并允许用户下载文件,使用参数指定文件名.如果开发人员忽略了代码中的授权,攻击者现在可以使用它下载系统文件(例如，网站代码或服务器数据:如备份)等.
不安全的直接对象引用漏洞的另一个例子是密码重置函数,该函数依赖用户输入来确定其身份.单击有效的URL后,攻击者可以修改URL中的字段,使其显示类似"admin"用户名的内容
预防
使用内部代码执行,不要使用外部参数来执行
安全配置错误
遇到配置错误的服务器和网站是很常见的,例如:
- 在生产环境中运行启用了调试程序
- 在服务器上启用目录列表(可能泄露某些私密信息)
- 运行非常古老的程序
- 运行不必要的服务
- 不更改默认密钥和密码(别以为没有"傻子",这种情况太多了)
- 向潜在攻击者泄露错误处理信息(堆栈跟踪)
预防
周期内修改密码,修复默认端口(22,3306,3389,21如果是外部可以访问的情况下),更新最新版本的程序.或积极维护现有可能潜在的bug漏洞,千万别再生产环境使用调试模式或开启debug等.
敏感数据泄露
此安全漏洞与加密和资源保护有关.敏感数据应该始终进行加密,包括传输中的数据和静态数据.没有例外!用户密码等不应传输或未加密存储,并且密码应始终应该进行哈希处理.
会话ID和敏感数据不应在URL中传输,这一点怎么强调都不为过.包含敏感数据的Cookie应打开"secure".
预防
使用HTTPS传输,Cookie打开secure,不需要或非必要的的数据及时删除,没人可以说数据不可能被盗取.所有密码都使用哈希加密.
缺少功能级的访问控制
如果在服务器上调用函数时未执行适当的授权,则会发生这种情况.开发人员倾向于假设,由于服务器端生成页面,客户端将无法访问服务器未提供的功能.但是事情并没有那么简单,因为攻击者总是可以伪造对"隐藏"功能的请求.假设有一个面板,并且该按钮仅在用户实际上是管理员时才会显示.如果缺少授权,没有什么能阻止攻击者发现和滥用此功能.
预防：在服务器端，必须始终验证或执行授予的权限.
跨站点请求伪造 （CSRF）
在CSRF中，恶意的第三方,欺骗浏览器滥用其权限来进行操作.
例如:攻击者A想通过将B的部分钱转入A的账户.
B操作之后传输完成正常应该显示:https://example.com/xxx?amount=100&Account=123456
A知道B经常访问A控制的网站,因此A在B的网站上放置了以下代码片段：
https://A.blog.com<img src=https://example.com/xxx?amount=100&Account=67890 width=0 height=0 />
当B下次访问网站时,浏览器错误地认为片段链接到图像.浏览器会自动发出获取图片的请求.但是,该请求没有在浏览器中显示图像,而是B的A转账100元.
预防
将机密令牌存储在第三方站点无法访问的隐藏表单字段中
使用具有已知漏洞的程序或插件
标题说明了一切
预防
不要一味的复制粘贴代码或使用某些代码.先认真看好代码,判断是否安全.
经常更新并使用最新的版本
未经验证的重定向和转发
这是另一个输入过滤问题.假设目标站点具有将URL作为参数.操作参数可以创建一个将浏览器重定向到的URL.用户会看到链接,它看起来无害,足以信任和点击.但是单击此链接可能会将用户转移到恶意软件的页面。或者转向到攻击者自己的钓鱼网站内.
预防
- 不要做重定向
- 当需要重定向时,需要有一个有效重定向位置的静态列表或数据库.
- 将自定义参数列入白名单(不过跟麻烦)
当然条件允许的话可以使用腾讯云旗下的安全产品:T-Sec 云防火墙、T-Sec Web应用防火墙、T-Sec 主机安全、容器安全服务TCSS、T-Sec 安全运营中心、T-Sec 漏洞扫描服务 等.
产品都有很成熟的解决方案.省时省力.
最后祝大家代码不出BUG,永远在线.
