皮皮网
皮皮网

【杏彩源码点卡充值修复】【pythonbox源码】【urimatcher源码】本地验证注入器源码_本地验证注入器源码是什么

来源:斗神再临游戏源码 发表时间:2024-12-24 01:59:54

1.【黑客编程】手把手教你编写POC
2.洞态IAST检测RuoYi的本地sql注入漏洞
3.从源码层面带你实现一个自动注入注解
4.ASP.NET Core认证原理和实现

本地验证注入器源码_本地验证注入器源码是什么

【黑客编程】手把手教你编写POC

       POC(全称:Proof of concept), 中文译作概念验证。在安全界可以理解成漏洞验证程序。验证源码和一些应用程序相比,注入证注PoC 是器源一段不完整的程序,仅仅是码本为了证明提出者的观点的一段代码。

       本次漏洞使用DVWA(Damn Vulnerable Web App) 是地验杏彩源码点卡充值修复一个用来进行安全脆弱性鉴定的PHP/MySQL Web 应用,旨在为安全专业人员测试自己的入器专业技能和工具提供合法的环境,帮助web开发者更好的本地理解web应用安全防范的过程。mihun渗透靶场 已经集成DVWA。验证源码

       登入DVWA系统,注入证注将DVWA Security 修改为low,器源本次使用 Command Injection(命令注入) 模块作为此次POC验证漏洞点。码本

       Command Injection(命令注入) 模块用于验证网络是地验pythonbox源码否通畅,由于对输入的入器参数检查不严格导致任意命令执行。

       Command Injection 模块源码

       分析上面源码发现ip参数未过滤被带入命令执行函数shell_exec,本地利用linux/win命令特性拼接参数 sechelper.cn&whoami 伪代码如下:

       使用PyCharm 创建一个python项目

       使用火狐浏览器按F 开启Firebug开发者模式,选择网络 重新触发漏洞观察/yangzongzhuan/RuoYi/archive/refs/tags/v4.6.1.zip][0]。

       官方文档:[https://hxsecurity.github.io/DongTaiDoc/#/doc/tutorial/plugin][0]

       运行项目:利用插件功能“Run With IAST”或“Debug With IAST”启动应用。

       漏洞检测:测试应用功能,urimatcher源码被动挖掘漏洞。访问“角色管理”功能时,发现存在SQL注入漏洞的[http://localhost/system/role/list的POST请求][0]。

       查看“漏洞列表”面板,确认漏洞。

       总结:测试表明,源码cp洞态IAST在漏洞检测方面表现良好,多次检测确认了RuoYi的其他漏洞,并验证了这些漏洞的真实性。洞态IAST的IDEA插件简化了漏洞检测过程,只需在IDEA中运行项目即可进行检测,十分便捷。轰炸+源码强烈推荐大家尝试使用。

       参考:本测试报告基于实际操作,结合了洞态IAST与RuoYi的使用文档与实践经验。

从源码层面带你实现一个自动注入注解

       首先,需要了解到的是。SpringBean的生命周期

       在生命周期中。注入bean属性的位置是在以下代码:populateBean位置中

       那么我们在项目中使用注解产生一个bean的时候必定会经过以下代码进行一个bean的创建流程

/**省略代码**///开始初始化bean实例对象ObjectexposedObject=bean;try{ //<5>对bean进行填充,将各个属性值注入,其中,可能存在依赖于其他bean的属性populateBean(beanName,mbd,instanceWrapper);//<6>调用初始化方法exposedObject=initializeBean(beanName,exposedObject,mbd);}catch(Throwableex){ if(exinstanceofBeanCreationException&&beanName.equals(((BeanCreationException)ex).getBeanName())){ throw(BeanCreationException)ex;}else{ thrownewBeanCreationException(mbd.getResourceDescription(),beanName,"Initializationofbeanfailed",ex);}}/**省略代码**/

       在生命周期中populateBean进行填充bean数据。把其他依赖引入进来

       BeanPostProcessor是一个bean创建时候的一个钩子。

       以下代码是循环调用实现了BeanPostProcessor子类InstantiationAwareBeanPostProcessor#postProcessProperties方法

       Spring在以下代码中有自动注入的拓展点。关键就是实现InstantiationAwareBeanPostProcessor#postProcessProperties

/**省略代码**/for(BeanPostProcessorbp:getBeanPostProcessors()){ if(bpinstanceofInstantiationAwareBeanPostProcessor){ InstantiationAwareBeanPostProcessoribp=(InstantiationAwareBeanPostProcessor)bp;//对所有需要依赖检查的属性进行后处理PropertyValuespvsToUse=ibp.postProcessProperties(pvs,bw.getWrappedInstance(),beanName);if(pvsToUse==null){ //从bw对象中提取PropertyDescriptor结果集//PropertyDescriptor:可以通过一对存取方法提取一个属性if(filteredPds==null){ filteredPds=filterPropertyDescriptorsForDependencyCheck(bw,mbd.allowCaching);}pvsToUse=ibp.postProcessPropertyValues(pvs,filteredPds,bw.getWrappedInstance(),beanName);if(pvsToUse==null){ return;}}pvs=pvsToUse;}}/**省略代码**/

       我们展开来讲一下@Autowired的实现是怎么样的吧:

       实现类为AutowiredAnnotationBeanPostProcessor.java

       从上面可以得知,填充bean的时候。时调用了方法ibp.postProcessPropertyValues()

       那么AutowiredAnnotationBeanPostProcessor#postProcessPropertyValues()则会被调用

       调用findAutowiringMetadata获取class以及父类带有@Autowired或者@Value的属性或者方法:

/**省略代码**/publicPropertyValuespostProcessProperties(PropertyValuespvs,Objectbean,StringbeanName){ //获取所有可以注入的元数据InjectionMetadatametadata=findAutowiringMetadata(beanName,bean.getClass(),pvs);try{ //注入数据metadata.inject(bean,beanName,pvs);}catch(BeanCreationExceptionex){ throwex;}catch(Throwableex){ thrownewBeanCreationException(beanName,"Injectionofautowireddependenciesfailed",ex);}returnpvs;}privateInjectionMetadatafindAutowiringMetadata(StringbeanName,Class<?>clazz,@NullablePropertyValuespvs){ //缓存名字获取StringcacheKey=(StringUtils.hasLength(beanName)?beanName:clazz.getName());InjectionMetadatametadata=this.injectionMetadataCache.get(cacheKey);//获取是否已经读取过这个class类的InjectionMetadata有的话直接从缓存中获取出去if(InjectionMetadata.needsRefresh(metadata,clazz)){ synchronized(this.injectionMetadataCache){ //双重检查metadata=this.injectionMetadataCache.get(cacheKey);if(InjectionMetadata.needsRefresh(metadata,clazz)){ if(metadata!=null){ metadata.clear(pvs);}//构建自动注入的元数据metadata=buildAutowiringMetadata(clazz);this.injectionMetadataCache.put(cacheKey,metadata);}}}returnmetadata;}privateInjectionMetadatabuildAutowiringMetadata(finalClass<?>clazz){ if(!AnnotationUtils.isCandidateClass(clazz,this.autowiredAnnotationTypes)){ returnInjectionMetadata.EMPTY;}List<InjectionMetadata.InjectedElement>elements=newArrayList<>();Class<?>targetClass=clazz;do{ finalList<InjectionMetadata.InjectedElement>currElements=newArrayList<>();//循环targetClass的所有field并执FieldCallback逻辑(函数式编程接口,传入的是一个执行函数)ReflectionUtils.doWithLocalFields(targetClass,field->{ //获得字段上面的Annotation注解MergedAnnotation<?>ann=findAutowiredAnnotation(field);if(ann!=null){ //判断是否为静态属性如果是,则不进行注入if(Modifier.isStatic(field.getModifiers())){ if(logger.isInfoEnabled()){ logger.info("Autowiredannotationisnotsupportedonstaticfields:"+field);}return;}//注解是否为必须依赖项booleanrequired=determineRequiredStatus(ann);currElements.add(newAutowiredFieldElement(field,required));}});//循环targetClass的所有Method并执MethodCallback逻辑(函数式编程接口,传入的是一个执行函数)ReflectionUtils.doWithLocalMethods(targetClass,method->{ MethodbridgedMethod=BridgeMethodResolver.findBridgedMethod(method);if(!BridgeMethodResolver.isVisibilityBridgeMethodPair(method,bridgedMethod)){ return;}MergedAnnotation<?>ann=findAutowiredAnnotation(bridgedMethod);if(ann!=null&&method.equals(ClassUtils.getMostSpecificMethod(method,clazz))){ //判断是否为静态方法如果是,则不进行注入if(Modifier.isStatic(method.getModifiers())){ if(logger.isInfoEnabled()){ logger.info("Autowiredannotationisnotsupportedonstaticmethods:"+method);}return;}//判断静态方法参数是否为0if(method.getParameterCount()==0){ if(logger.isInfoEnabled()){ logger.info("Autowiredannotationshouldonlybeusedonmethodswithparameters:"+method);}}booleanrequired=determineRequiredStatus(ann);PropertyDescriptorpd=BeanUtils.findPropertyForMethod(bridgedMethod,clazz);currElements.add(newAutowiredMethodElement(method,required,pd));}});//数据加到数组最前方父类的的注解都放在靠前的位置elements.addAll(0,currElements);//如果有父类则设置targetClass为父类。如此循环targetClass=targetClass.getSuperclass();}while(targetClass!=null&&targetClass!=Object.class);returnInjectionMetadata.forElements(elements,clazz);}/**省略代码**/

       真正注入数据的是metadata.inject(bean,beanName,pvs);

       调用的是InjectionMetadata#inject方法

publicvoidinject(Objecttarget,@NullableStringbeanName,@NullablePropertyValuespvs)throwsThrowable{ Collection<InjectedElement>checkedElements=this.checkedElements;//带有注解的方法或者属性列表Collection<InjectedElement>elementsToIterate=(checkedElements!=null?checkedElements:this.injectedElements);if(!elementsToIterate.isEmpty()){ for(InjectedElementelement:elementsToIterate){ element.inject(target,beanName,pvs);}}}

       循环调用之前加入的带有注解的方法或者属性构建的对象AutowiredFieldElement#inject,AutowiredMethodElement#inject

/***属性上有注解构建的处理对象*/privateclassAutowiredFieldElementextendsInjectionMetadata.InjectedElement{ privatefinalbooleanrequired;privatevolatilebooleancached;@NullableprivatevolatileObjectcachedFieldValue;publicAutowiredFieldElement(Fieldfield,booleanrequired){ super(field,null);this.required=required;}@Overrideprotectedvoidinject(Objectbean,@NullableStringbeanName,@NullablePropertyValuespvs)throwsThrowable{ //获取属性名Fieldfield=(Field)this.member;Objectvalue;//Bean不是单例的话,会重复进入注入的这个操作,if(this.cached){ try{ value=resolvedCachedArgument(beanName,this.cachedFieldValue);}catch(NoSuchBeanDefinitionExceptionex){ //Unexpectedremovaloftargetbeanforcachedargument->re-resolvevalue=resolveFieldValue(field,bean,beanName);}}else{ //首次创建的时候进入该方法value=resolveFieldValue(field,bean,beanName);}if(value!=null){ //属性如果不为public的话,则设置为可访问ReflectionUtils.makeAccessible(field);field.set(bean,value);}}@NullableprivateObjectresolveFieldValue(Fieldfield,Objectbean,@NullableStringbeanName){ //构建DependencyDescriptor对象DependencyDescriptordesc=newDependencyDescriptor(field,this.required);desc.setContainingClass(bean.getClass());//注入bean的数量。有可能字段上是一个ListSet<String>autowiredBeanNames=newLinkedHashSet<>(1);Assert.state(beanFactory!=null,"NoBeanFactoryavailable");//获得beanFactory类型转换类TypeConvertertypeConverter=beanFactory.getTypeConverter();Objectvalue;try{ //查找依赖关系value=beanFactory.resolveDependency(desc,beanName,autowiredBeanNames,typeConverter);}catch(BeansExceptionex){ thrownewUnsatisfiedDependencyException(null,beanName,newInjectionPoint(field),ex);}synchronized(this){ if(!this.cached){ ObjectcachedFieldValue=null;if(value!=null||this.required){ cachedFieldValue=desc;//填入依赖关系registerDependentBeans(beanName,autowiredBeanNames);//判断如果注入依赖是只有一个if(autowiredBeanNames.size()==1){ StringautowiredBeanName=autowiredBeanNames.iterator().next();if(beanFactory.containsBean(autowiredBeanName)&&beanFactory.isTypeMatch(autowiredBeanName,field.getType())){ cachedFieldValue=newShortcutDependencyDescriptor(desc,autowiredBeanName,field.getType());}}}this.cachedFieldValue=cachedFieldValue;this.cached=true;}}returnvalue;}}/***方法上有注解构建的处理对象*/privateclassAutowiredMethodElementextendsInjectionMetadata.InjectedElement{ privatefinalbooleanrequired;privatevolatilebooleancached;@NullableprivatevolatileObject[]cachedMethodArguments;publicAutowiredMethodElement(Methodmethod,booleanrequired,@NullablePropertyDescriptorpd){ super(method,pd);this.required=required;}@Overrideprotectedvoidinject(Objectbean,@NullableStringbeanName,@NullablePropertyValuespvs)throwsThrowable{ //检查属性是不会在之前就已经注入过了。如果主如果则不进行二次覆盖if(checkPropertySkipping(pvs)){ return;}Methodmethod=(Method)this.member;Object[]arguments;if(this.cached){ try{ arguments=resolveCachedArguments(beanName);}catch(NoSuchBeanDefinitionExceptionex){ //Unexpectedremovaloftargetbeanforcachedargument->re-resolvearguments=resolveMethodArguments(method,bean,beanName);}}else{ //首次创建的时候进入该方法arguments=resolveMethodArguments(method,bean,beanName);}if(arguments!=null){ try{ //属性如果不为public的话,则设置为可访问ReflectionUtils.makeAccessible(method);//调用方法并传入参数method.invoke(bean,arguments);}catch(InvocationTargetExceptionex){ throwex.getTargetException();}}}@NullableprivateObject[]resolveCachedArguments(@NullableStringbeanName){ Object[]cachedMethodArguments=this.cachedMethodArguments;if(cachedMethodArguments==null){ returnnull;}Object[]arguments=newObject[cachedMethodArguments.length];for(inti=0;i<arguments.length;i++){ arguments[i]=resolvedCachedArgument(beanName,cachedMethodArguments[i]);}returnarguments;}@NullableprivateObject[]resolveMethodArguments(Methodmethod,Objectbean,@NullableStringbeanName){ //获取方法上有几个参数intargumentCount=method.getParameterCount();Object[]arguments=newObject[argumentCount];DependencyDescriptor[]descriptors=newDependencyDescriptor[argumentCount];Set<String>autowiredBeans=newLinkedHashSet<>(argumentCount);Assert.state(beanFactory!=null,"NoBeanFactoryavailable");TypeConvertertypeConverter=beanFactory.getTypeConverter();for(inti=0;i<arguments.length;i++){ //方法参数,从方法参数中取出i构造MethodParameter对象MethodParametermethodParam=newMethodParameter(method,i);DependencyDescriptorcurrDesc=newDependencyDescriptor(methodParam,this.required);currDesc.setContainingClass(bean.getClass());descriptors[i]=currDesc;try{ //获取方法中i参数的内容Objectarg=beanFactory.resolveDependency(currDesc,beanName,autowiredBeans,typeConverter);if(arg==null&

ASP.NET Core认证原理和实现

       é€šå¸¸åœ¨åº”用程序中,安全分为前后两个步骤:验证和授权。验证负责检查当前请求者的身份,而授权则根据上一步得到的身份决定当前请求者是否能够访问期望的资源。

        既然安全从验证开始,我们也就从验证开始介绍安全。

        我们先从比较简单的场景开始考虑,例如在 Web API 开发中,需要验证请求方是否提供了安全令牌,安全令牌是否有效。如果无效,那么 API 端应该拒绝提供服务。在命名空间 Microsoft.AspNetCore.Authentication 下,定义关于验证的核心接口。对应的程序集是 Microsoft.AspNetCore.Authentication.Abstractions.dll。

        在 ASP.NET 下,验证中包含 3 个基本操作:

        验证操作负责基于当前请求的上下文,使用来自请求中的信息,例如请求头、Cookie 等等来构造用户标识。构建的结果是一个 AuthenticateResult 对象,它指示了验证是否成功,如果成功的话,用户标识将可以在验证票据中找到。

        常见的验证包括:

        在授权管理阶段,如果用户没有得到验证,但所期望访问的资源要求必须得到验证的时候,授权服务会发出质询。例如,当匿名用户访问受限资源的时候,或者当用户点击登录链接的时候。授权服务会通过质询来相应用户。

        例如

        质询操作应该让用户知道应该使用何种验证机制来访问请求的资源。

        在授权管理阶段,如果用户已经通过了验证,但是对于其访问的资源并没有得到许可,此时会使用拒绝操作。

        例如:

        拒绝访问处理应该让用户知道:

        在这个场景下,可以看到,验证需要提供的基本功能就包括了验证和验证失败后的拒绝服务两个操作。在 ASP.NET Core 中,验证被称为 Authenticate,拒绝被称为 Forbid。 在供消费者访问的网站上,如果我们希望在验证失败后,不是像 API 一样直接返回一个错误页面,而是将用户导航到登录页面,那么,就还需要增加一个操作,这个操作的本质是希望用户再次提供安全凭据,在 ASP.NET Core 中,这个操作被称为 Challenge。这 3 个操作结合在一起,就是验证最基本的要求,以接口形式表示,就是 IAuthenticationHandler 接口,如下所示:

        验证的结果是一个 AuthenticateResult 对象。值得注意的是,它还提供了一个静态方法 NoResult() 用来返回没有得到结果,静态方法 Fail() 生成一个表示验证异常的结果,而 Success() 成功则需要提供验证票据。

        通过验证之后,会返回一个包含了请求者票据的验证结果。

        在 GitHub 中查看 AuthenticateResult 源码

        那么验证的信息来自哪里呢?除了前面介绍的 3 个操作之外,还要求一个初始化的操作 Initialize,通过这个方法来提供当前请求的上下文信息。

        在 GitHub 中查看 IAuthenticationHandler 定义

        有的时候,我们还希望提供登出操作,增加登出操作的接口被称为 IAuthenticationSignOutHandler。

        在 GitHub 中查看 IAuthenticationSignOutHandler 源码

        在登出的基础上,如果还希望提供登录操作,那么就是 IAuthenticationSignInHandler 接口。

        在 GitHub 中查看 IAuthenticationSignInHandler 源码

        直接实现接口还是比较麻烦的,在命名空间 Microsoft.AspNetCore.Authentication 下,微软提供了抽象基类 AuthenticationHandler 以方便验证控制器的开发,其它控制器可以从该控制器派生,以取得其提供的服务。

        通过类的定义可以看到,它使用了泛型。每个控制器应该有一个对应该控制器的配置选项,通过泛型来指定验证处理器所使用的配置类型,在构造函数中,可以看到它被用于获取对应的配置选项对象。

        在 GitHub 中查看 AuthenticationHandler 源码

        通过 InitializeAsync(),验证处理器可以获得当前请求的上下文对象 HttpContext。

        最终,作为抽象类的 ,希望派生类来完成这个验证任务,抽象方法 HandleAuthenticateAsync() 提供了扩展点。

        验证的结果是一个 AuthenticateResult。

        而拒绝服务则简单的多,直接在这个抽象基类中提供了默认实现。直接返回 HTTP 。

        剩下的一个也一样,提供了默认实现。直接返回 HTTP 响应。

        对于 JWT 来说,并不涉及到登入和登出,所以它需要从实现 IAuthenticationHandler 接口的抽象基类 AuthenticationHandler 派生出来即可。从 AuthenticationHandler 派生出来的 JwtBearerHandler 实现基于自己的配置选项 JwtBearerOptions。所以该类定义就变得如下所示,而构造函数显然配合了抽象基类的要求。

        在 GitHub 中查看 JwtBearerHandler 源码

        真正的验证则在 HandleAuthenticateAsync() 中实现。下面的代码是不是就很熟悉了,从请求头中获取附带的 JWT 访问令牌,然后验证该令牌的有效性,核心代码如下所示。

        在 GitHub 中查看 JwtBearerHandler 源码

        在 ASP.NET Core 中,你可以使用各种验证处理器,并不仅仅只能使用一个,验证控制器需要一个名称,它被看作该验证模式 Schema 的名称。Jwt 验证模式的默认名称就是 "Bearer",通过字符串常量 JwtBearerDefaults.AuthenticationScheme 定义。

        在 GitHub 中查看 JwtBearerDefaults 源码

        最终通过 AuthenticationBuilder 的扩展方法 AddJwtBearer() 将 Jwt 验证控制器注册到依赖注入的容器中。

        在 GitHub 中查看 JwtBearerExtensions 扩展方法源码

        一种验证处理器,加上对应的验证配置选项,我们再为它起一个名字,组合起来就成为一种验证架构 Schema。在 ASP.NET Core 中,可以注册多种验证架构。例如,授权策略可以使用架构的名称来指定所使用的验证架构来使用特定的验证方式。在配置验证的时候,通常设置默认的验证架构。当没有指定验证架构的时候,就会使用默认架构进行处理。

        还可以

        注册的验证模式,最终变成 AuthenticationScheme,注册到依赖注入服务中。

        在 GitHub 中查看 AuthenticationScheme 源码

        各种验证架构被保存到一个 IAuthenticationSchemeProvider 中。

        在 GitHub 中查看 IAuthenticationSchemeProvider 源码

        最终的使用是通过 IAuthenticationHandlerProvider 来实现的,通过一个验证模式的字符串名称,可以取得所对应的验证控制器。

        在 GitHub 中查看 IAuthenticationHandlerProvider 源码

        它的默认实现是 AuthenticationHandlerProvider,源码并不复杂。

        在 GitHub 中查看 AuthenticationHandlerProvider 源码

        验证中间件的处理就没有那么复杂了。

        找到默认的验证模式,使用默认验证模式的名称取得对应的验证处理器,如果验证成功的话,把当前请求用户的主体放到当前请求上下文的 User 上。

        里面还有一段特别的代码,用来找出哪些验证处理器实现了 IAuthenticationHandlerProvider,并依次调用它们,看看是否需要提取终止请求处理过程。

        在 GitHub 中查看 AuthenticationMiddle 源码

相关栏目:探索