随着技术的不断发展,应用安全会逐渐在各个领域扮演越来越重要的角色。在应用安全为主题角度,相对来说比较全面的指导,OWASP Cheat Sheet Series应该不能不被提及,如下:
(图片来自:https://cheatsheetseries.owasp.org/Glossary.html)
这个可以为我们了解应用安全的方向找到一个切口。供大家学习和了解。
下面几个日常相对常见的几种安全漏洞:
在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(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
跨站脚本(英语:Cross-site scripting,通常简称为:XSS)是一种网站应用程序的安全漏洞攻击,是代码注入的一种。它允许恶意用户将代码注入到网页上,其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。
“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的角度触发,对系统打补丁。实际上,它是通过对于请求头的恶意注入引起的恶意调用远程命令执行。
所以直接在注入的入口封死也能够解决对应的安全扫描漏洞问题,正则表达式判断是否是对http请求头中进行的恶意注入,正则如下:
/echo|\(|\)|{|}/g
可能会窃取或操纵客户会话和 cookie,它们可能用于模仿合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务
可能原因:Web 应用程序设置了缺少 HttpOnly 属性的会话 cookie
技术描述:在应用程序测试过程中,检测到所测试的 Web 应用程序设置了不含“HttpOnly”属性的会话 cookie。由于此会话 cookie 不包含“HttpOnly”属性,因此植入站点的恶意脚本可能访问此 cookie,并窃取它的值。任何存储在会话令牌中的信息都可能被窃取,并在稍后用于身份盗窃或用户伪装。
为了解决这种方式,在cookie中给对应的项加上HttpOnly属性就可以了。
可能会检索有关站点文件系统结构的信息,这可能会帮助攻击者映射此 Web 站点
常规
如果不需要禁止的资源,请将其从站点中除去。可能的话,请发出改用“404 - 找不到”响应状态代码,而不是“403 - 禁止”。这项更改会将站点的目录模糊化,可以防止泄漏站点结构。
技术描述
Web 应用程序显现了站点中的目录。虽然目录并没有列出其内容,但此信息可以帮助攻击者发展对站点进一步的攻击。例如,知道目录名称之后,攻击者便可以猜测它的内容类型,也许还能猜出其中的文件名或子目录,并尝试访问它们。内容的敏感度越高,此问题也可能越严重。