一行代码引来的安全漏洞,防DDoS就让我们丢失了整个服务器的操纵权-墨者安全-墨者盾
DDOS防御_CC防护_高防CDN服务器_【墨者安全】—墨者盾墨者盾—你的网站贴身保镖!
QQ:800185041
高防免费接入:400-0797-119

渠道合作:156 2527 6999

主页 > CC防护 > 一行代码引来的安全漏洞,防DDoS就让我们丢失了整个服务器的操纵权

一行代码引来的安全漏洞,防DDoS就让我们丢失了整个服务器的操纵权

小墨安全管家 2020-06-16 20:04 CC防护 89 ℃
DDoS防御
感觉就如此就完了吗?

}  

}  

@ExceptionHandler(BadRequestException.class)  

一行代码引来的安全漏洞,就让我们丢失了整个服务器的操纵权

}  

@Override  

接着在各个语言资源文件中配置好相应的错误信息提示即可。其中, @Gender 算是一具自定义的注解。

public class CustomValidator implements ConstraintValidator<CustomParam, String> {  

String i18message = getI18nMessage(e.getKey(), request);  

return messageSource.getMessage(key, null, LanguaggeUtils.currentLocale(request));  

场景重现

一切都显得特别完美,直到上线前代码提交至安全团队扫描,就被“啪啪打脸”,扫描报告反馈了一具严峻的安全漏洞。而那个安全漏洞,属于特别高危的远程代码执行漏洞。

一行代码引来的安全漏洞,就让我们丢失了整个服务器的操纵权

@Documented  

关于以上约束,我们只需要在对应的字段上添加如下注解即可。

return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(Response.error(e.getCode(), i18message));  

public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) {  

}  

@Target({FIELD, METHOD, PARAMETER, ANNOTATION_TYPE})  

}  

private String email;  

@Gender(message="validate.userRegForm.gender")  

@Retention(RetentionPolicy.RUNTIME)  

我们跟踪下对应的代码,看看内部实现,就会“恍然大悟”了。

认真看,那个想法实际上是 
org.hibernate.validator.messageinterpolation.AbstractMessageInterpolator.interpolateMessage。

@Retention(RetentionPolicy.RUNTIME)  

 

ConstraintValidatorContext那个接口中声明的,看想法名字事实上能懂输入参数是一具字符串模板,内部会举行解析替换的(这事实上也符合“见名知意”的良好编程习惯)。(教训:大伙儿应该把握好自个儿写的每一行代码背后实际在做啥。)

if (s.equals("tanglei")) {  

private static void error(ConstraintValidatorContext context, String message) {  

……

关于表单的约束,我们有:

咨询题就出如今实现自定义注解举行校验的这行代码(如下图所示):

}  

return key;  

private String getI18nMessage(String key, HttpServletRequest request) {  

}  

不同语言的资源文件示例

catch (Exception e) {  

public void initialize(CustomParam constraintAnnotation) {  

}  

 

昵称字段:“nickname” 必填,长度必须是 6 到 20 位;

String message() default "name.tanglei.";  

假如大概的话,需要对开辟者的代码举行漏洞扫描。一些常见的安全漏洞如今应该是有现成的工具支持的。另外,让专业的人做专业的情况,例如要有安全团队,大概你会讲你们公司没有不也活的好好的,哈哈,只只是大概还没有被坏人盯上而已,坏人也会思量到他们的成本和预期收益的,固然这就更加对我们开辟者提高了要求。一些敏感权限尽可能操纵在少部分人手中,配合相应的流程来支撑(不得不讲,大公司繁琐的流程依旧有一定道理的)。

上面例子只为了阐述讲明咨询题,其中校验逻辑没有实际意义,如此,假如输入参数不满脚条件,就会明确提示用户输入的哪个参数不满脚条件。例如输入参数 xx,则会直截了当提示:Invalid params: xx。

private String gender;  

/* ......  

我们构造恰当的 EL 表达式(注意各种转义,下文的输入参数相对照较明显在做啥了,实际上还有更多黑科技,比如各种二进制转义编码啊等等),就能直截了当执行输入代码,例如:能够直截了当执行命令,“ls -al”, 返回了一具 UNIXProcess 实例,命令基本被执行过了。

}  

任何时候都不要相信用户的输入,必须对用户输入的举行校验和过滤,又非常是针对公网上的应用。

 

事实上,最开始的时候,那个地点直截了当返回了“Invalid params”,当初为了更好的用户体验,要明确告诉用户哪个参数没有经过校验,所以在输出的提示上加上了用户输入的字段,也算是上面的"Invalid params: " + s,没想到,这闯了大祸了(回过头来想,感受那个地点没必要那样详细啊,因为前端基本有相应的校验了,正常事情下回挡住,针对不守规矩的用很规手段来的接口请求,直截了当返回校验不经过就行了,怎么讲不是对外提供的 OpenAPI 服务)。

return ResponseEntity.status(HttpStatus.OK).body(Response.error(e.getCode(), i18message));  

下面我们就一起来看看那个事故,啊,不对,是故事。

这还得了吗?这相当于提供了一具 webshell 的功能呀,你看想运行什么命令就能运行什么命令,例如 ping 本人博客地址(ping ),下面动图演示一下整个过程(从运行 ping 到 kill ping)。

怎么讲我不是专业研究Web安全的,以上讲的大概也不一定对,假如你有不接受见或者更好的建议欢迎留言参与讨论。

定义的表单如下:

@ExceptionHandler(ErrorCodeException.class)  

校验逻辑的实现 CustomValidator:

德国用户看到的是:“Der von Ihnen eingegebene Verifizierungscode ist abgelaufen, bitte wiederholen” 。(我瞎找的翻译,不一定准)

@ControllerAdvice  

}  

// log  

public @interface CustomParam {  

* @param messageTemplate new un-interpolated constraint message  

 

@Length(min = 6, max = 20, message = "validate.userRegForm.nickname")  

假设找回密码时,需要用户输入手机或者邮箱验证码,假设那个时候用户输入的验证码经过后台数据库(大概是Redis)对照发觉基本过期。在业务代码中,只需要简单的 throw new ErrorCodeException(

岂不是直截了当创建一具用户,接着远程登录就能够了。后果特别严峻啊,别人想干嘛就干嘛了。

用前文提到的自定义 Validator,输入的参数用: “1+1=${1+1}”,看看效果:

* @return returns a constraint violation builder  

邮箱: “email”,必填,必须满脚邮箱格式。

context.buildConstraintViolationWithTemplate(message).addConstraintViolation();  


DDoS防御

当前位置:主页 > CC防护 > 一行代码引来的安全漏洞,防DDoS就让我们丢失了整个服务器的操纵权

标签列表
DDoS防御
网站分类
X
 

QQ客服

400-0797-119