web开发常见安全漏洞

XXE（XML External Entity）

原理

XXE攻击是一种针对应用程序处理XML数据的安全漏洞。在这种攻击中，攻击者利用XML解析器处理外部实体的方式，来执行恶意操作。这可能包括访问本地文件系统、执行远程代码、拒绝服务攻击等。

XML文档可以定义实体，这些实体可以是文档内部的，也可以是外部的。外部实体（External Entity）通常用于从外部源加载数据。在XXE攻击中，攻击者通过在XML输入中包含恶意内容，试图利用应用程序的XML解析器来执行未授权的操作。

示例

假设有一个应用程序接受XML输入并解析它。攻击者可以发送如下XML文档：

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

在这个例子中，定义了一个名为 xxe 的外部实体，它尝试从本地文件系统加载 /etc/passwd 文件（在Unix系统中包含用户账户信息）。如果XML解析器处理这个实体，它将返回 /etc/passwd 文件的内容。

解决方案

1. 禁用外部实体: 配置XML解析器禁用外部实体的处理。这是防止XXE攻击的最有效方法。
2. 使用最新的库: 确保使用的XML解析器和库是最新的，因为许多现代的解析器默认禁用外部实体。
3. 最小化XML功能: 如果可能，限制XML功能，只使用必要的功能。
4. 输入验证: 对输入的XML数据进行严格的验证，确保它符合预期的格式。
5. 错误处理: 在解析XML时，正确处理错误和异常，避免泄露敏感信息。

这里就禁用外部实体来进行介绍，其它解决方法根据自己实际使用方式来进行使用。

在Java中，如果你使用 DocumentBuilderFactory 来解析XML，可以这样配置来防止XXE攻击：

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);

FEATURE = "http://xml.org/sax/features/external-general-entities";
dbf.setFeature(FEATURE, false);

FEATURE = "http://xml.org/sax/features/external-parameter-entities";
dbf.setFeature(FEATURE, false);

FEATURE = "http://apache.org/xml/features/nonvalidating/load-external-dtd";
dbf.setFeature(FEATURE, false);

dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

对于其它工具类的方案可以参考：LeadroyaL/java-xxe-defense-demo: java xxe defense demo (github.com)

CSRF(Cross-Site Request Forgery)

原理

CSRF攻击是一种网络攻击，攻击者诱使已认证的用户在不知情的情况下发送恶意请求。这种攻击利用了Web应用程序中用户的登录状态和信任。攻击者通过在第三方网站上嵌入恶意代码或链接，诱导用户执行非预期的操作（如更改密码、转账等）。

具体的攻击步骤如下：

1. 用户登录: 用户登录到Web应用程序（如银行网站）并在浏览器中保持登录状态。
2. 恶意请求: 用户访问了一个包含恶意代码的第三方网站。这个代码或链接包含了对受信任网站的请求。
3. 自动发送请求: 由于用户已经登录到受信任的网站，浏览器会自动发送请求，同时附带用户的认证信息（如Cookies）。
4. 执行非预期操作: 受信任的网站接收到请求，并在用户不知情的情况下执行了操作。

示例

假设用户登录到他们的银行网站，然后在不退出的情况下访问了一个恶意网站。这个恶意网站上有以下HTML代码：

<img src="https://bank.com/transfer?to=attacker&amount=1000" style="display:none;">

当用户访问这个恶意网站时，浏览器会尝试加载这个图片，实际上会向银行网站发送一个转账请求。由于用户已经登录，请求会被认为是合法的。

解决方案

1. 使用CSRF令牌: 在每个表单或敏感操作请求中使用一个唯一的CSRF令牌。服务器验证这个令牌是否有效。
2. 检查Referer头: 服务器可以检查HTTP请求的Referer头，以确保请求是从受信任的源发起的。
3. 使用SameSite Cookie属性: 设置Cookies的SameSite属性为Strict或Lax，这可以防止浏览器在跨站请求中发送这些Cookies。
4. 双重提交Cookie: 将CSRF令牌存储在用户的会话中，并在每个请求中从用户的Cookie中获取相同的令牌进行比较。
5. 自定义请求头: 使用自定义请求头（如X-Requested-With），并在服务器端验证这个头的存在。

这里以使用CSRF令牌解决方案为例，具体的解决方案可根据实际使用场景进行调整

<form action="/transfer" method="post">
    <input type="hidden" name="csrf_token" value="RANDOM_TOKEN_FROM_SERVER">
    <!-- 其他表单字段 -->
</form>

服务器端在处理请求时，会验证csrf_token字段是否与用户会话中的令牌匹配。

SQL注入

原理

SQL注入是一种常见的网络安全攻击，它允许攻击者通过在Web应用程序的输入字段中插入恶意SQL代码来操纵或破坏后端数据库。这种攻击发生在应用程序未能适当地清理或转义用户输入的情况下。

具体的攻击步骤如下：

1. 用户输入处理: 应用程序接收用户输入（如表单数据、URL参数等）并将其作为SQL查询的一部分。
2. 未经验证的输入: 如果输入未经验证或清理，攻击者可以在其中嵌入恶意SQL代码。
3. 恶意SQL执行: 当这个恶意输入作为SQL查询的一部分在数据库上执行时，它可能会泄露敏感信息、删除数据、或执行其他恶意操作。

示例

假设有一个Web应用程序，它允许用户通过输入用户名来检索账户信息。后端代码如下所示：

String query = "SELECT * FROM users WHERE username = '" + userInput + "'";

如果攻击者在输入中使用了如下字符串：

' OR '1'='1

那么最终的SQL查询将变成：

SELECT * FROM users WHERE username = '' OR '1'='1';

这个查询将返回所有用户的信息，因为 '1'='1' 总是为真。

解决方案

1. 使用参数化查询: 使用参数化查询是防止SQL注入的最有效方法。这种方法确保用户输入被安全地处理，并且不会被解释为SQL代码的一部分。
2. 使用ORM框架: 使用对象关系映射（ORM）框架可以减少直接的SQL代码编写，ORM通常内置了防止SQL注入的措施。
3. 输入验证和清理: 对所有用户输入进行严格的验证和清理，确保它们不包含潜在的恶意代码。
4. 最小化权限: 确保数据库账户仅具有执行必要操作所需的最小权限，避免使用具有广泛数据库访问权限的账户。
5. 错误处理: 避免在错误消息中暴露数据库信息，这可能为攻击者提供攻击线索。

这里以参数化查询为例：

在Java中，使用 PreparedStatement 来实现参数化查询：

String query = "SELECT * FROM users WHERE username = ?";
PreparedStatement statement = connection.prepareStatement(query);
statement.setString(1, userInput);
ResultSet results = statement.executeQuery();

通过这种方式，即使用户输入包含SQL代码，它也会被数据库处理为普通字符串，而不是SQL命令的一部分。

SSRF(Server-Side Request Forgery)

原理

SSRF攻击是一种网络安全漏洞，它允许攻击者迫使服务器端应用程序向攻击者指定的内部或外部资源发起请求。这种攻击利用了服务器端应用程序对URL资源的请求功能。

具体的攻击步骤如下：

1. 利用服务器端请求: Web应用程序通常会根据用户输入或API调用向其他系统或服务发起请求。例如，从URL下载图片、访问API等。
2. 未经验证的输入: 如果应用程序未对用户提供的URL进行适当的验证和限制，攻击者可以提供恶意URL。
3. 访问内部资源: 通过这种方式，攻击者可以让服务器访问内部网络中的资源，这些资源对外部攻击者来说通常是不可达的。
4. 数据泄露或恶意操作: 攻击者可能利用这种方式访问敏感数据、利用内部服务的漏洞，或对内部系统进行恶意操作。

示例

假设有一个Web应用程序，它允许用户提供一个URL来下载图片。代码如下所示：

URL url = new URL(userInput);
InputStream input = url.openStream();
// 处理输入流...

如果攻击者输入了一个指向内部系统的URL（例如，http://internal-company-database/loadData），应用程序可能会尝试访问并下载该内部资源的数据。

解决方案

1. 严格的输入验证: 对所有用户提供的URL进行严格的验证。只允许格式正确且安全的URL。
2. 限制URL范围: 限制应用程序可以访问的URL范围。例如，只允许访问特定域名或协议。
3. 使用安全列表: 维护一个安全的URL列表，并确保只有列表中的URL被允许。
4. 禁用不必要的URL方案: 禁用对于应用程序不必要的URL方案，例如 file:// 或 ftp://。
5. 超时和错误处理: 为所有外部请求设置合理的超时，并正确处理错误和异常。
6. 网络隔离和监控: 确保服务器与敏感内部资源之间有适当的网络隔离，并监控异常的网络活动。

下面就输入验证方案举例说明：

URL url = new URL(userInput);
if (!isUrlAllowed(url)) {
   
    throw new SecurityException("URL is not allowed");
}
// 继续处理URL...

其中 isUrlAllowed 是一个函数，用于检查URL是否符合安全标准，例如检查它是否属于允许的域名列表。具体的方案可以根据实际需求进行自定义。

XFF（X-Forwarded-For）漏洞

X-Forwarded-For（XFF）是一个HTTP头部，通常用于识别通过HTTP代理或负载均衡器进行连接的客户端的原始IP地址。在某些情况下，攻击者可能会尝试操纵X-Forwarded-For头部来欺骗服务器或绕过IP地址限制。

原理

1. 信任XFF头部: 一些Web应用程序和服务器配置为信任X-Forwarded-For头部来确定客户端的真实IP地址。这在使用代理或负载均衡器的环境中很常见。
2. 伪造XFF头部: 攻击者可以在其HTTP请求中伪造或操纵X-Forwarded-For头部，试图欺骗服务器认为请求来自不同的IP地址。
3. 绕过安全控制: 如果应用程序或安全策略依赖于IP地址进行访问控制或速率限制，攻击者可能利用伪造的XFF头部绕过这些限制。

示例

假设一个Web应用程序使用X-Forwarded-For头部来实施速率限制或访问控制。攻击者可以发送如下HTTP请求：

GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-For: 1.2.3.4

在这个例子中，攻击者伪造了X-Forwarded-For头部，试图让应用程序认为请求来自IP地址1.2.3.4。

解决方案

1. 谨慎信任XFF头部: 仅在可信的代理或负载均衡器背后运行的环境中信任X-Forwarded-For头部。
2. 使用安全列表: 如果可能，配置服务器或应用程序只信任来自已知代理或负载均衡器的X-Forwarded-For头部。
3. 限制头部操纵: 在网络边界（如防火墙或边缘路由器）配置规则，以删除或重置来自不可信源的X-Forwarded-For头部。
4. 结合其他安全措施: 不要仅依赖于IP地址进行安全控制。结合使用其他安全措施，如身份验证、令牌和行为分析。
5. 日志和监控: 记录和监控异常的X-Forwarded-For使用模式，以便及时发现潜在的攻击。

在Web服务器（如Nginx或Apache）中，你可以配置服务器只信任来自特定代理的X-Forwarded-For头部。例如，在Nginx中：

set_real_ip_from 192.168.1.10;  # 可信代理的IP地址
real_ip_header X-Forwarded-For;

这样配置后，Nginx只会从IP地址为192.168.1.10的代理接受X-Forwarded-For头部。

a.对于直接使用的 Web 应用，必须使用从TCP连接中得到的 Remote Address，才是用户真实的IP

location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true; }

使用 Nginx 等 Web Server 进行反向代理的 Web 应用，在第一台中间件配置正确的前提下（直接访问WEB应用的场景），后端服务器则使用nginx传过来的相应IP地址作为用户真实IP；同时，后端服务器应使用X-Real-IP 或 X-Forwarded-For最后1段IP作为限制（（因为 Remote Address 得到的是 Nginx 所在服务器的内网 IP）），允许自己的nginx服务器访问，禁止其它IP访问，禁止对外提供服务。

后面的二级三级代理服务器：

location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_set_header X-NginX-Proxy true; }

b.对于tomcat的配置，修改tomcat配置文件server.xml

<HOST>
 <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
          prefix="localhost_access_log." suffix=".txt"
          pattern="%{X-Forwarded-For}i %h %l %u %t %r %s %b %{Referer}i %{User-Agent}i" resolveHosts="false" />   #注意如果前端没有nginx跳转的话，将X-Forwarded-For替换成X-Real-IP
</HOST>

XSS（Cross-Site Scripting）

XSS攻击是一种在用户的浏览器中执行恶意脚本的安全漏洞。它允许攻击者注入未经过滤的或未经逃逸的代码到Web页面中，这些代码随后会被其他用户的浏览器执行。XSS攻击通常用于窃取用户的会话令牌、登录凭证、破坏网页内容或重定向到恶意网站。

原理

1. 用户输入: Web应用程序接收用户输入，如表单提交、URL参数等。
2. 未经适当处理的输入: 如果应用程序未对用户输入进行适当的清理或转义，恶意输入可能会被包含在输出的HTML中。
3. 执行恶意脚本: 当其他用户访问包含恶意输入的页面时，嵌入其中的脚本会在他们的浏览器中执行。

示例

假设有一个Web应用程序，它允许用户发表评论，并将这些评论直接显示在页面上。如果应用程序未对用户输入进行转义，攻击者可以输入以下内容：

<script>alert('XSS Attack');</script>

这段脚本将被嵌入到页面中，并在其他用户浏览该页面时执行。

解决方案

1. 输入转义: 对所有用户输入进行HTML转义，特别是在将其嵌入HTML页面时。这意味着将字符如<、>、"、'等转换为HTML实体。
2. 使用内容安全策略（CSP）: 实施CSP可以限制Web页面上可以执行的脚本。例如，可以禁止执行所有内联脚本。
3. 验证和清理输入: 使用库如OWASP Java HTML Sanitizer来清理输入，确保移除或转义所有潜在的恶意内容。
4. 使用HTTP头部加强安全性: 设置适当的HTTP头部，如X-Content-Type-Options: nosniff和X-XSS-Protection: 1; mode=block，可以提高浏览器的安全性。
5. 框架的内置防护: 许多现代Web框架（如React、Angular、Vue.js）自带XSS防护机制，确保使用这些框架的特性来处理用户输入。

这里以通过输入转义为例：

在一个基于Java的Web应用程序中，你可以在显示用户输入之前进行转义：

String safeInput = StringEscapeUtils.escapeHtml4(userInput);

在这个例子中，StringEscapeUtils.escapeHtml4方法来自Apache Commons Lang库，它会转义HTML中的特殊字符。

路劲遍历漏洞

路径遍历（也称为目录遍历）攻击是一种网络安全漏洞，它允许攻击者通过修改应用程序的输入数据来访问或操纵文件系统上不应该被访问的文件。这种攻击利用了Web应用程序对用户输入的不当处理，特别是在处理文件名和路径时。

原理

1. 用户输入处理: Web应用程序接收用户输入，如文件名或路径，用于文件操作（如打开、读取、写入文件）。
2. 未经适当过滤的输入: 如果应用程序未对用户输入进行适当的过滤或验证，攻击者可以插入诸如../（在Unix-like系统中）或..\（在Windows系统中）这样的序列来“遍历”文件系统。
3. 访问受限文件: 通过这种方式，攻击者可能能够访问或操纵应用程序目录之外的文件，这可能包括配置文件、源代码、敏感个人数据等。

示例

假设一个Web应用程序允许用户下载指定的日志文件，如http://example.com/download?file=logfile.txt。如果应用程序直接将file参数的值用于文件路径，攻击者可以请求http://example.com/download?file=../../../../etc/passwd，尝试访问Unix系统的密码文件。

解决方案

1. 输入验证: 严格验证用户输入。不要直接将用户输入用于文件路径或命令。特别是要过滤像../或..\这样的序列。
2. 使用安全的API: 使用处理文件路径和访问的安全API。例如，避免使用直接对文件系统进行操作的低级API。
3. 限制文件访问: 限制Web应用程序可以访问的文件范围。例如，仅允许访问特定目录下的文件。
4. 使用白名单: 维护一个允许访问的文件的白名单，并确保只有这些文件可以被访问。
5. 错误处理: 在发生错误（如文件不存在）时，不要向用户显示具体的文件系统路径或其他敏感信息。
6. 运行时权限: 确保Web应用程序以限制的权限运行，以减少攻击者通过路径遍历攻击能够造成的损害。

这里以输入验证为例，给出一个简单的示例：

import java.util.regex.Pattern;

public class InputValidationExample {
   
    // 正则表达式，用于验证文件名
    private static final String FILE_NAME_PATTERN = "^[a-zA-Z0-9._-]+$";
    public static void main(String[] args) {
   
        // 测试输入
        String userInput = "example.txt";
        if (isValidFileName(userInput)) {
   
            System.out.println("Valid file name: " + userInput);
            // 进行文件操作
        } else {
   
            System.out.println("Invalid file name: " + userInput);
            // 处理无效输入
        }
    }
    // 验证文件名是否有效
    private static boolean isValidFileName(String fileName) {
   
        Pattern pattern = Pattern.compile(FILE_NAME_PATTERN);
        return pattern.matcher(fileName).matches();
    }
}

在这个示例中，我们定义了一个正则表达式FILE_NAME_PATTERN，它只允许字母、数字、点号、下划线和短横线。这样可以有效地防止包含如../或..\这样的路径遍历序列的文件名。然后，我们使用Pattern和Matcher类来检查用户输入的文件名是否符合这个模式。

注意事项

• 正则表达式应根据实际应用场景进行调整。在不同的上下文中，有效的输入可能会有所不同。
• 输入验证是防止注入攻击的重要手段之一，但它并不能解决所有安全问题。应结合其他安全措施（如使用安全的API、最小权限原则等）来提高应用程序的整体安全性。
• 对于更复杂的输入验证需求，可以考虑使用专门的验证库，如Apache Commons Validator。

高危端口非授权访问

高危端口非授权访问攻击是指攻击者试图访问Web服务器或相关网络设备上未经授权的高危端口。这些端口可能运行着敏感的服务，如数据库、管理接口或开发工具，它们通常不应对公众开放。攻击者通过扫描这些端口来寻找安全漏洞，以便进行进一步的攻击，如数据泄露、服务破坏或未经授权的系统访问。

原理

目前大多数程序安装在服务器上后，往往会开启多个端口，由于服务默认配置，服务器上面经常会出现大量的端口开放，同时服务未配置认证，从而导致大多数端口直接可以被访问。

例如：redis服务，Redis 默认情况下会绑定在 0.0.0.0:6379，这样将会将 Redis 服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。docker方式部署redis，不会加载redis.conf；因此所有人都可以直接连接redis服务，进而直接获取信息；

常见高危端口：

端口	服务	渗透测试
tcp 20,21	FTP（文件传输协议）	允许匿名的上传下载,爆破,嗅探,win提权,远程执行(proftpd 1.3.5),各类后门(proftpd,vsftp 2.3.4)
tcp 22	SSH （安全外壳协议 ）	可根据已搜集到的信息尝试爆破,v1版本可中间人,ssh隧道及内网代理转发,文件传输等等
tcp 23	Telnet （ 远程终端协议）	爆破,嗅探,一般常用于路由,交换登陆,可尝试弱口令
tcp 25	SMTP（简单邮件传输协议）	邮件伪造,vrfy/expn查询邮件用户信息,可使用smtp-user-enum工具来自动跑
tcp/udp 53	DNS（域名系统）	允许区域传送,dns劫持,缓存投毒,欺骗以及各种基于dns隧道的远控
tcp/udp 69	TFTP （简单文件传送协议 ）	尝试下载目标及其的各类重要配置文件
tcp 80-89,443,8440-8450,8080-8089	各种常用的Web服务端口	可尝试经典的topn,vpn,owa,webmail,目标oa,各类Java控制台,各类服务器Web管理面板,各类Web中间件漏洞利用,各类Web框架漏洞利用等等……
tcp 110	POP3（邮局协议版本3 ）	可尝试爆破,嗅探
tcp 111,2049	NFS（网络文件系统）	权限配置不当
tcp 137,139,445	SMB（NETBIOS协议）	可尝试爆破以及smb自身的各种远程执行类漏洞利用,如,ms08-067,ms17-010,嗅探等……
tcp 143	IMAP（邮件访问协议）	可尝试爆破
udp 161	SNMP（简单网络管理协议）	爆破默认团队字符串,搜集目标内网信息
tcp 389	LDAP（ 轻量目录访问协议 ）	ldap注入,允许匿名访问,弱口令
tcp 512,513,514	Linux rexec （远程登录）	可爆破,rlogin登陆
tcp 873	Rsync （数据镜像备份工具）	匿名访问,文件上传
tcp 1194	OpenVPN（虚拟专用通道）	想办法钓VPN账号,进内网
tcp 1352	Lotus（Lotus软件）	弱口令,信息泄漏,爆破
tcp 1433	SQL Server（数据库管理系统）	注入,提权,sa弱口令,爆破
tcp 1521	Oracle（甲骨文数据库）	tns爆破,注入,弹shell…
tcp 1500	ISPmanager（ 主机控制面板）	弱口令
tcp 1723	PPTP（点对点隧道协议 ）	爆破,想办法钓VPN账号,进内网
tcp 2082,2083	cPanel （虚拟机控制系统 ）	弱口令
tcp 2181	ZooKeeper（分布式系统的可靠协调系统 ）	未授权访问
tcp 2601,2604	Zebra （zebra路由）	默认密码zerbra
tcp 3128	Squid （代理缓存服务器）	弱口令
tcp 3312,3311	kangle（web服务器）	弱口令
tcp 3306	MySQL（数据库）	注入,提权,爆破
tcp 3389	Windows rdp（桌面协议）	shift后门[需要03以下的系统],爆破,ms12-020
tcp 3690	SVN（开放源代码的版本控制系统）	svn泄露,未授权访问
tcp 4848	GlassFish（应用服务器）	弱口令
tcp 5000	Sybase/DB2（数据库）	爆破,注入
tcp 5432	PostgreSQL（数据库）	爆破,注入,弱口令
tcp 5900,5901,5902	VNC（虚拟网络控制台，远控）	弱口令爆破
tcp 5984	CouchDB（数据库）	未授权导致的任意指令执行
tcp 6379	Redis（数据库）	可尝试未授权访问,弱口令爆破
tcp 7001,7002	WebLogic（WEB应用系统）	Java反序列化,弱口令
tcp 7778	Kloxo（虚拟主机管理系统）	主机面板登录
tcp 8000	Ajenti（Linux服务器管理面板）	弱口令
tcp 8443	Plesk（虚拟主机管理面板）	弱口令
tcp 8069	Zabbix （系统网络监视）	远程执行,SQL注入
tcp 8080-8089	Jenkins,JBoss （应用服务器）	反序列化,控制台弱口令
tcp 9080-9081,9090	WebSphere（应用服务器）	Java反序列化/弱口令
tcp 9200,9300	ElasticSearch （Lucene的搜索服务器）	远程执行
tcp 11211	Memcached（缓存系统）	未授权访问
tcp 27017,27018	MongoDB（数据库）	爆破,未授权访问
tcp 50070,50030	Hadoop（分布式文件系统）	默认端口未授权访问

示例

假设一个Web服务器错误地将其数据库管理界面（如phpMyAdmin）配置在了一个对外开放的高危端口（例如8080）。攻击者通过扫描发现了这个端口，并利用了管理界面上的一个漏洞来获取数据库的访问权限。

解决方案

1.白名单限制

REDIS：

修改redis.conf配置文件，进行侦听IP限制；

bind 127.0.0.1

MongoDB：

修改mongodb.conf文件中添加以下内容：

bind_ip = 127.0.0.1

Elasticsearch：

修改elasticsearch.yml文件，修改IP白名单：

http.basic.ipwhitelist ["localhost", "127.0.0.1"]

Memcache：

无权限控制功能，只能对访问源控制

memcached -d -m 1024 -u root -l 127.0.0.1 -p 11211 -c 1024 -P /tmp/memcached.pid

CouchDB :

修改couchdb/local.ini文件，添加以下内容：

bind_address = 127.0.0.1

2.启用身份认证，权限限制等

REDIS：

修改redis.conf配置文件

# 开启密码验证
requirepass mypassword
# 禁止高危命令：
rename-command FLUSHALL ""
rename-command CONFIG ""
rename-command EVAL ""
# 启用保护模式
protected-mode yes

MongoDB：

启动时添加-auth参数，开启数据库访问身份认证

mongo
use admin
db.createUser({
   
    user: "myAdminUser",
    pwd: "myAdminPassword",
    roles: [ {
    role: "userAdminAnyDatabase", db: "admin" } ]
})

Elasticearch：

修改elasticsearch.yml文件，为9200端口配置认证：

http.basic.enabled true #开关，开启会接管全部HTTP连接
http.basic.user “admin” #账号
http.basic.password “admin_pw” #密码

Zookeeper：

进入Zookeeper后，配置策略；

1）增加一个认证用户

addauth digest 用户名:密码明文
addauth digest user1:password1

2）设置权限

setAcl /path digest:用户名:密码密文:权限
setAcl /path digest:用户名:密码密文:权限

couchDB：

修改couchdb/local.ini文件

# 给[admins]配置密码
[admins]
admin = yourpassword
# 设置WWW-Authenticate，强制认证
[chttpd]
WWW-Authenticate = basic

3.防火墙全局策略

如果业务明确的前提下，可以在服务器本地开启防火墙策略，直接对外来的IP进行白名单策略控制；

综上，介绍了常见的web开发中遇到的一些安全漏洞，这里没有列举完全，其余的还有文件上传漏洞、命令注入漏洞、用户名枚举、未授权访问、短信验证码爆破等等，漏洞永远存在，我们能做的就是不断提升我们系统的安全性，争取将其漏洞风险降到最低，查缺补漏，不断升级才是完全之策。