原代码审计笔记-安全缺陷
URL重定向：
问题示例：
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
String location = req.getParameter("url");
resp.sendRedirect(location); // Noncompliant
}原因分析：
通过重定向，Web 应用程序能够引导用户访问同一应用程序内的不同网页或访问外部站点。应用程序利用重定向来帮助进行站点导航，有时还跟踪用户退出站点的方式。当 Web 应用程序将客户端重定向到攻击者可以控制的任意 URL 时，就会发生 Open redirect 漏洞：
攻击者可以利用 Open redirect 漏洞诱骗用户访问某个可信赖站点的 URL，并将他们重定向到恶意站点。攻击者通过对 URL 进行编码，使最终用户很难注意到重定向的恶意目标，即使将这一目标作为 URL 参数传递给可信赖的站点时也会发生这种情况。因此，Open redirect 常被作为钓鱼手段的一种而滥用，攻击者通过这种方式来获取最终用户的敏感数据。
如果允许未验证的输入控制重定向机制所使用的 URL，可能会有利于攻击者发动钓鱼攻击。
解决方案：
建议：过滤即将重定向的路径，或者增设黑白名单实现安全访问限制。
不安全的SSL(过于宽泛的证书信托)：
问题示例：
TrustManager[] trustAllCerts = new TrustManager[]{new X509TrustManager() {
public java.security.cert.X509Certificate[] getAcceptedIssuers() {
return null;
}
public void checkClientTrusted(X509Certificate[] certs, String authType) {
}
public void checkServerTrusted(X509Certificate[] certs, String authType) {
}
}原因分析：
过于信任证书，没有对证书进行校验和约束，或是校验不完善。
公钥基础架构 (PKI) 基于受信任的证书颁发机构 (CA)，但盗用的证书颁发机构的数量不断增加，这意味着其根证书无法再受到信任，因此由该 CA 签名的证书也不再受到信任。拥有这些盗用证书的攻击者将能够拦截所有信任这些 CA 的 SSL/TLS 信息流。
证书颁发机构的签名对于浏览器等通用网络通信工具而言是必不可少的，这些工具连接到任意网络端点，并且事先并不知道哪些 CA 对这些端点的 SSL/TLS 证书进行了签名。对于连接到有限的后端服务器的移动应用程序，如果它们知道这些服务器在对其证书进行签名时可能会使用的若干受信任 CA，则这些应用程序可从中获益，并在应用程序中“固定”这些证书/公钥，以便仅信任应用程序需要的证书。
SSL/TLS 连接使用默认的预加载系统证书颁发机构 (CA) 创建，这可能会使攻击者利用由盗用的根 CA 签名的证书执行中间人 (MiTM) 攻击，从而拦截加密通信。
解决方案：
建议：CA签名的证书执行中间人(MiTM)攻击，建议对证书有效性有完善的校验、使用时间短、2048位加密长度的SSL证书。次则如果使用默认的URLConnection建立SSL/TLS连接，建议使用HttpsURLConnection进行替代，并对证书进行判断和处理。
反射型跨站脚本：
问题示例：
public void risk(HttpServletRequest request,
HttpServletResponse response ,org.apache.log4j.Logger logger) {
String text = request.getParameter("text");
try {
response.getWriter().print(text);
} catch (IOException e) {
logger.warn(“Exception”, e);
}
}原因分析：
Cross-Site Scripting (XSS) 漏洞在以下情况下发生：
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS，不可信赖的源通常为 Web 请求，而对于 Persisted（也称为 Stored）XSS，该源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据，便将其传送给了 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 代码片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私人数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。
向一个 Web 浏览器发送未经验证的数据会导致该浏览器执行恶意代码。
解决方案：
建议：反射型跨站，来自用户输入的字符串被直接输出到客户端。
1、使用跨站修复函数处理输出到客户端的数据字符串。
例如：
1.使用struts自带的跨站修复函数方式：
String filtedText = org.apache.struts.util.ResponseUtils.filter(text);
response.getWriter().print(filtedText);
2.未使用struts的系统，使用自定义的跨站修复函数方式
String encodeText = encodeHtml(text);
response.getWriter().print(encodeText);
3.使用Apache的commons-lang.jar提供系统库函数StringEscapeUtils.escapeHtml(str)：
String encodeText = StringEscapeUtils.escapeHtml(text);
response.getWriter().print(encodeText);
2、设置cookie时使用HttpOnly参数，限制cookie作为DOM对象存取，避免攻击者利用跨站脚本漏洞进行Cookie劫持攻击。
3、次则需要设置过滤库或者黑白名单，确保浏览器不会执行恶意代码。
存储型跨站脚本：
问题示例：
protected void printComment(Connection conn, ServletOutputStream out, String user) throws SQLException, IOException {
PreparedStatement pr = conn.prepareStatement("SELECT * FROM comms WHERE user = ?");
pr.setString(0, user);
String comment = pr.executeQuery().getString("comment");
out.println("Comments: " + comment);
}原因分析：
Cross-Site Scripting (XSS) 漏洞在以下情况下发生：
1.数据通过一个不可信赖的数据源进入 Web 应用程序。对于 Reflected XSS，不可信赖的源通常为 Web 请求，而对于 Persisted（也称为 Stored）XSS，该源通常为数据库或其他后端数据存储。
2. 未检验包含在动态内容中的数据，便将其传送给了 Web 用户。
传送到 Web 浏览器的恶意内容通常采用 JavaScript 代码片段的形式，但也可能会包含一些 HTML、Flash 或者其他任意一种可以被浏览器执行的代码。基于 XSS 的攻击手段花样百出，几乎是无穷无尽的，但通常它们都会包含传输给攻击者的私人数据（如 Cookie 或者其他会话信息）。在攻击者的控制下，指引受害者进入恶意的网络内容；或者利用易受攻击的站点，对用户的机器进行其他恶意操作。
向一个 Web 浏览器发送未经验证的数据会导致该浏览器执行恶意代码。
解决方案：
建议：存储型跨站，来自用户输入的字符串被直接输出到客户端。
1、使用esapi处理输出到客户端的数据字符串，例如：org.owasp.encoder.Encode.forHtml(name);。
2、次则需要设置过滤库或者黑白名单，确保浏览器不会执行恶意代码。
路径操纵：
问题示例：
public boolean authenticate(javax.servlet.http.HttpServletRequest request) {
String user = request.getParameter("user");
// If the special value "../bin" is passed as user, authentication is bypassed
// Indeed, if it passed as a user, the path becomes:
// /bin
// which exists on most Linux / BSD / Mac OS distributions
return Files.exists(Paths.get("/home/", user)); // Noncompliant
}原因分析：
当满足以下两个条件时，就会产生 path manipulation 错误：
1. 攻击者可以指定某一文件系统操作中所使用的路径。
2. 攻击者可以通过指定特定资源来获取某种权限，而这种权限在一般情况下是不可能获得的。
例如，在某一程序中，攻击者可以获得特定的权限，以重写指定的文件或是在其控制的配置环境下运行程序。 例 1： 下面的代码使用来自于 HTTP 请求的输入来创建一个文件名。程序员没有考虑到攻击者可能使用像“ ../../tomcat/conf/server.xml”一样的文件名，从而导致应用程序删除它自己的配置文件。
String rName = request.getParameter("reportName");
File rFile = new File("/usr/local/apfr/reports/" + rName);
...
rFile.delete();
允许用户输入控制文件系统操作所用的路径会导致攻击者能够访问或修改其他受保护的系统资源。
解决方案：
建议：对访问文件路径有过滤限制或者增设黑白名单，限制访问权限，确保访问是安全的、允许访问的 。
发布评论