WEB安全

问问计算机

发布于 2021-09-03 14:18:36

1.5K0

发布于 2021-09-03 14:18:36

文章被收录于专栏：问问计算机

随着技术的不断发展，应用安全会逐渐在各个领域扮演越来越重要的角色。在应用安全为主题角度，相对来说比较全面的指导，OWASP Cheat Sheet Series应该不能不被提及，如下：

（图片来自：https://cheatsheetseries.owasp.org/Glossary.html）

这个可以为我们了解应用安全的方向找到一个切口。供大家学习和了解。

下面几个日常相对常见的几种安全漏洞：

SQL盲注

在appscan中对SQL盲注的解释是：可能会查看、修改或删除数据库条目和表，如下图：

appscan中提供的了保护 Web 应用程序免遭 SQL 注入攻击的两种可行方法：

「1」使用存储过程，而不用动态构建的 SQL 查询字符串。将参数传递给 SQL Server 存储过程的方式，可防止使用单引号和连字符

「2」可以使用验证控件，将输入验证添加到“Web 表单”页面。验证控件提供适用于所有常见类型的标准验证的易用机制

注意事项：验证控件不会阻止用户输入或更改页面处理流程；它们只会设置错误状态，并产生错误消息。程序员的职责是，在执行进一步的应用程序特定操作前，测试代码中控件的状态。

有两种方法可检查用户输入的有效性：

①测试常规错误状态：在您的代码中，测试页面的 IsValid 属性。该属性会将页面上所有验证控件的 IsValid 属性值汇总（使用逻辑 AND）。如果将其中一个验证控件设置为无效，那么页面属性将会返回 false。

②测试个别控件的错误状态：在页面的“验证器”集合中循环，该集合包含对所有验证控件的引用。然后，可以检查每个验证控件的 IsValid 属性。

一份好的设计通常需要 Web 应用程序框架，以提供服务器端实用程序例程，从而验证以下内容：

① 必需字段

②字段数据类型（缺省情况下，所有 HTTP 请求参数都是“字符串”）

③ 字段长度

④ 字段范围

⑤ 字段选项

⑥ 字段模式

⑦ cookie 值

⑧ HTTP 响应好的做法是将以上例程作为“验证器”实用程序类中的静态方法实现。

通常防御SQL注入的方法：

①白名单

②参数化查询

③WAF

④RASP

从概念上对于SQL注入和阻止方法，可以参考 SQL Injection and How to Prevent It? SQL Injection Prevention Cheat Sheet

在SQL Injection Prevention Cheat Sheet中对于防御注入的方法进行了一部分代码层次的说明。相对来说能够在一定程度上帮助理解。

实用的情况下，针对注入，拿springboot的java项目来说，可以使用validation注解，对于指定的规则进行拦截。参考如下内容：

https://blog.csdn.net/justry_deng/article/details/86571671

https://blog.csdn.net/qq_41762594/article/details/109326971

CSRF

CSRF（Cross Site Request Forgery，跨站请求伪造，也叫 XSRF）被 OWASP 组织列为十大 Web 漏洞威胁之一，可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务。简单来说，攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。

CSRF跨站请求的场景，如下：

1.用户访问网站，登录后在浏览器中存下了cookie的信息

2.用户在某些诱导行为下点击恶意网址，恶意网站借助脚本获取其他的cookie

3.在得到目标cookie后，肆意破坏

针对Referer拦截的防御实践：

①在asp.net mvc中的处理方式如下：

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {

            if ((System.Web.HttpContext.Current.Request.UrlReferrer != null && System.Web.HttpContext.Current.Request.UrlReferrer.Host != System.Web.HttpContext.Current.Request.Url.Host))
            {
                Response.Write("输入你返回页面的消息，比如加微信：changyandoublog 获取拉勾教育免费课");
                //直接返回，不再回到后续的Action操作
                filterContext.Result = new HttpNotFoundResult();
            }
        }

②asp.net core

（图片来自：https://docs.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-5.0）

③SpringBoot 通过拦截器验证Referer 防御CSRF攻击

拦截器：

@Component
public class RefererInterceptor extends HandlerInterceptorAdapter {
    // URL匹配器
    private AntPathMatcher matcher = new AntPathMatcher();
    @Autowired
    private RefererProperties properties;
    @Override
    public boolean preHandle(HttpServletRequest req, HttpServletResponse resp, Object handler) throws Exception {
        String referer = req.getHeader("referer");
        String host = req.getServerName();
        // 只验证POST请求
        if ("POST".equals(req.getMethod())) {
            if (referer == null) {
                resp.setStatus(HttpServletResponse.SC_NOT_FOUND);
                return false;
            }
            URL url = null;
            try {
                url = new URL(referer);
            } catch (MalformedURLException e) {
                resp.setStatus(HttpServletResponse.SC_NOT_FOUND);
                return false;
            }
            if (!host.equals(url.getHost())) {
                if (properties.getRefererDomain() != null) {
                    for (String s : properties.getRefererDomain()) {
                        if (s.equals(url.getHost())) {
                            return true;
                        }
                    }
                }
                return false;
            }
        }
        return true;
    }
}

实体：

//如果不使用@Data的情况下，可能会出现RefererProperties无法正常取值，并且拦截过程中定义的 properties 为空的情况
@Data
@Component
@ConfigurationProperties(prefix = "referer")
public class RefererProperties {
    // 白名单域名
    private List<String> refererDomain;
}

application.yml中的配置，设置refer白名单，实现不符合要求的全部拦截过滤，避免refer的csrf攻击

referer:
  refererDomain:
    - localhost
    - 127.0.0.1

XSS

跨站脚本（英语：Cross-site scripting，通常简称为：XSS）是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。

CSP

“Content-Security-Policy”头旨在修改浏览器呈现页面的方式，从而防止各种跨站点注入，包括跨站点脚本编制。请务必正确设置该头值，使其不会阻止网站的正确操作。例如，如果该头设置为阻止执行内联 JavaScript，则网站不得在其页面内使用内联 JavaScript。

为了防止跨站点脚本编制，请务必为‘default-src’策略或‘script-src’和‘object-src’设置正确值。应避免不安全值，如‘*’、‘data:’、‘unsafe-inline’或‘unsafe-eval’。

此外，为了防止跨框架脚本编制或点击劫持，请务必为‘frame-ancestors’策略设置正确值。应避免不安全值，如‘*’或‘data:’。

（图片来自：https://cloud.tencent.com/developer/section/1189876）

实现方式：

CSP in SpringBoot and JHipster

通过 Bash 进行远程命令执行（也称为 Shellshock，也称为 Bashdoor）Bashdoor)

有些地方是从Bash的角度触发，对系统打补丁。实际上，它是通过对于请求头的恶意注入引起的恶意调用远程命令执行。

所以直接在注入的入口封死也能够解决对应的安全扫描漏洞问题，正则表达式判断是否是对http请求头中进行的恶意注入，正则如下：

/echo|\(|\)|{|}/g

会话 cookie 中缺少 HttpOnly 属性

可能会窃取或操纵客户会话和 cookie，它们可能用于模仿合法用户，从而使黑客能够以该用户身份查看或变更用户记录以及执行事务

可能原因：Web 应用程序设置了缺少 HttpOnly 属性的会话 cookie

技术描述：在应用程序测试过程中，检测到所测试的 Web 应用程序设置了不含“HttpOnly”属性的会话 cookie。由于此会话 cookie 不包含“HttpOnly”属性，因此植入站点的恶意脚本可能访问此 cookie，并窃取它的值。任何存储在会话令牌中的信息都可能被窃取，并在稍后用于身份盗窃或用户伪装。

为了解决这种方式，在cookie中给对应的项加上HttpOnly属性就可以了。