WEB应用安全

开发 WEB 应用的同学应该不少，不知道大家平时开发中，有没有关注过应用开发的「安全问题」。

所谓安全问题，就是开发中不要留下漏洞，给入侵者破坏者机会。

比如，我们常挂在嘴边的安全问题有 「SQL 注入」，为了防止出现问题，一般都会使用预编译的 SQL，而不是拼接SQL，以此来保证安全。再比如，我们一个允许用户输入的文本框中，会禁用代码的渲染，比如像

<script>  alert(“hello”);</script>  这种会被做为纯文本对待。

类似需要注意的问题有很多，如果我们不留意，就会容易造成安全问题。

不过有些「洞」，是你我开发中不曾留意的。或者说你只有先意识到有这一类问题需要注意，开发的时候才会把它堵上。

比如最近开发的一个WEB 应用，公司做安全的同事帮忙看了看，就给报了几个问题。

这里简单总结和各位一起分享下，欢迎留言讨论。

同事给指出的问题主要有两个：

1. 不安全的  TRACE、OPTIONS 等方法未禁用
2. 用户提交的信息里， 可以包含第三方链接，容易出现钓鱼问题 。

问题一：

通过TRACE、OPTIONS 方法，可以暴露不少关键信息。

我们知道，HTTP 请求里可以使用不同的 Method 来实现不同的请求功能， 比如常见的 GET/POST/PUT/DELETE 。除此之外还有一些，比如 TRACE/OPTIONS 等，每种请求简单描述如下。详细描述，可以查看RFC2616(https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)

GET 请求指定的页面信息，并返回实体主体。
HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE 请求服务器删除指定的页面。
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS 允许客户端查看服务器的可用内容。
TRACE 回显服务器收到的请求，主要用于测试或诊断

从上面内容可以看出，TRACE 方法，OPTIONS方法，一般都会返回大量和实际业务处理无关的内容，如果开放会暴露许多服务器的关键信息，可能引出安全问题。

处理方式：

对于传统的web项目， 直接在web.xml 里增加安全限制「security-constraint」即可。

对于 Spring Boot应用，如果是使用 Tomcat做为容器，可以通过声明独立的配置，实现类似web.xml的效果：

web.xml的配置

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>PUT</http-method>
        <http-method>DELETE</http-method>
        <http-method>HEAD</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>TRACE</http-method>
    </web-resource-collection>
    <auth-constraint/>
</security-constraint>

Spring Boot 应用中的配置

@Configuration
public class TomcatCustomizer implements EmbeddedServletContainerCustomizer {

    @Override
    public void customize(ConfigurableEmbeddedServletContainer container) {
        TomcatEmbeddedServletContainerFactory tomcat = (TomcatEmbeddedServletContainerFactory) container;
        tomcat.setSessionTimeout(8, TimeUnit.HOURS);
        tomcat.addContextCustomizers(new ContextSecurityCustomizer());

    }
    private static class ContextSecurityCustomizer implements TomcatContextCustomizer {
        @Override
        public void customize(Context context) {
            SecurityConstraint constraint = new SecurityConstraint();
            SecurityCollection securityCollection = new SecurityCollection();
            securityCollection.setName("restricted_methods");
            securityCollection.addPattern("/*");
            securityCollection.addOmittedMethod(HttpMethod.POST.toString());
            securityCollection.addOmittedMethod(HttpMethod.GET.toString());
            constraint.addCollection(securityCollection);
            constraint.setAuthConstraint(true);
            context.addConstraint(constraint);
        }
    }

}

如果使用 Jetty，配置方式也类似。

当然，如果想要做到不与容器依赖紧耦合，还可以自己定义Filter，然后在请求中判断请求头里的 Method  如果是不允许的方法，可以直接返回错误。

问题二：

具体是这样，我们的应用里允许用户上传图片。上传的图片会保存到对象存储中，然后返回一个URL，最后用户完整的信息里，是直接存储了一个URL。但是，我们看到，整个上传到提交的过程，并不是一步完成的，所以，用户可以自行构造这个提交的请求， 并将图片的URL，替换成任意链接 。

这个时候，在页面再次渲染时，是会请求图片URL来展示图片的。如果是一个恶意的第三方钓鱼链接，容易造成盗取用户信息等安全问题。

处理方式：

这个问题，一般在后端对提交的内容进行检验，如果有「不符合规定」的域名，就报错。一般是维护一个白名单，判断URL信息在不在白名单中。

判断一个URL的后缀，你一般用什么方式呢？正则表达式？字符串截取？

这里有个方式供参考，可以直接取出我们预期的域名后缀：

String host = "";
URL fullUrl = null;
        try {
            fullUrl = new URL("http://blog.tomcat8080.com/abc=def");
        } catch (MalformedURLException e) {
            e.printStackTrace();
        }
        host = fullUrl.getHost();

        InternetDomainName domainName = InternetDomainName.from(host);
        String top = domainName.topPrivateDomain().toString();

这些安全技术，仿佛是和WEB开发平行的一个领域，属于另一个工种。这些不属于架构，与 设计模式 无关，也不在数据库设计、虚拟机优化的范围内，但是，也是我们不得不去认真了解和重视的。可能不需要安全工程师那么深入，但一些常见的安全问题要了解，类似于一个 「CheatSheet」避免自己开发的时候暴露，保证我们开发的应用安全，不被攻击和泄露数据。对于WEB安全，我还是 too young了，欢迎各位留言述说自己的经验。