项目思路---接口的权限控制、登陆校验以及白名单的设置

接口的权限控制、登陆校验以及白名单的设置

在登陆成功之后,才可以去访问一些接口,否则其他的接口都是不可以访问状态,或者校验这个用户在发起请求的时候,是否是登陆状态,同时有些接口不需要登陆也可以访问,在这里做一个简单的记录。

首先,在看到这些需求的时候,要在配置文件里面进行配置白名单,之后读取白名单的配置文件获取到白名单的列表,这样就可以拿到了那写接口不需要判断。

其次,要做一个拦截器,在每一次前台发起请求的时候,用来拦截,之后进行比较,如果是白名单接口,则不需要进行拦截,直接放掉,如果需要拦截,则进行拦截,进行业务判断。

在之后,根据业务逻辑,判断白名单,之后,判断登陆权限,在判断角色权限,最后抛出异常,返给前台,告知前台信息。

1、读取白名单,以及设置拦截器

2、根据业务进行处理。

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        Map<String,String> map = CommonUtils.getIpAddr(request);
        if (restList.contains(map.get("uri"))) {
            logger.info(map.get("uri")+"是白名单");
            return true;
        }

        // 检查每个到来的请求对应的session域中是否有登录标识
        Object loginName = request.getSession().getAttribute("loginName");
        if (null == loginName || !(loginName instanceof String)) {
            // 未登录,重定向到登录页
            throw new YzptException(CodeEnums.USER_TOKEN_FAIL);
        }
        String userName = (String) loginName;
        System.out.println("当前用户已登录,登录的用户名为: " + userName);
        return true;
    }

用于处理请求资源的信息方法。 

    public static Map<String ,String> getIpAddr(HttpServletRequest request) {

        Map<String ,String> map = new HashMap<String,String>();

        String uri = request.getRequestURI();//返回请求行中的资源名称
        String url = request.getRequestURL().toString();//获得客户端发送请求的完整url
        String params = request.getQueryString();//返回请求行中的参数部分
        String host = request.getRemoteHost();//返回发出请求的客户机的主机名
        int port = request.getRemotePort();//返回发出请求的客户机的端口号。

        String ip = request.getHeader("X-Forwarded-For");
        if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
            ip = request.getHeader("Proxy-Client-IP");
        }
        if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
            ip = request.getHeader("WL-Proxy-Client-IP");
        }
        if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
            ip = request.getHeader("HTTP_CLIENT_IP");
        }
        if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
            ip = request.getHeader("HTTP_X_FORWARDED_FOR");
        }
        if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {
            ip = request.getRemoteAddr();
        }
        map.put("host",host);
        map.put("params",params);
        map.put("url",url);
        map.put("uri",uri);
        map.put("port",String.valueOf(port));
        map.put("ip",ip);
        return map;
    }

总结:在做开始做项目的时候,需要将整体的流程想清楚,之后分解项目模块,在进行每一块的编写和处理,代码不是很全,之后接口权限的控制我还没有写,主要就是在session里面标记,这个用户的身份,之后在请求的时候,进行拦截判断用户身份是不是可以调用这个接口就好了,因为之前在写功能的时候,把这些功能都写在了上面,所以截图和代码不是特别全,可以加qq:1029273212索要源码,还有要是有大神能给我指点一二就更好了,期待和大家一起成长。

<think>嗯,用户想了解泛微E-Mobile的messageType.do命令执行漏洞的测试背景、成因、分析和解决方案。首先,我需要回忆一下这个漏洞的基本情况。记得泛微E-Mobile是泛微OA系统的移动端应用,可能因为某些接口未做充分的安全验证导致远程代码执行。比如,messageType.do这个接口可能存在参数未过滤,攻击者可以通过构造恶意请求执行系统命令。 接下来,测试背景方面,这个漏洞可能是在安全研究人员或渗透测试过程中发现的。通常这类漏洞的发现是因为公开的漏洞披露或者厂商的补丁公告。需要确认漏洞的CVE编号,比如CVE-2023-...,不过可能这个漏洞没有公开的CVE,而是通过其他渠道披露的。 成因方面,可能涉及反序列化漏洞、参数注入或者命令拼接。比如,用户输入的参数未经过滤直接传递给系统命令执行函数,比如Runtime.getRuntime().exec(),导致攻击者可以注入恶意命令。或者使用了不安全的框架,如存在漏洞的Apache Commons Collections库导致反序列化问题。 分析部分需要具体说明漏洞触发的路径,比如请求的URL、参数,以及如何构造payload。例如,messageType.do接口在处理messageType参数时,未做校验,直接将参数内容拼接到系统命令中执行。攻击者可以通过发送带有;或者&&等命令分隔符的请求,执行任意命令。 解决方案通常包括升级到官方修复版本,或者临时措施如WAF规则、禁用相关接口。需要查找泛微官方是否有发布补丁,或者给出配置修改的建议,比如在应用服务器上限制访问权限,过滤特殊字符等。 另外,用户提到了参考引用中的Microsoft Exchange漏洞,可能想类比其他反序列化或远程代码执行漏洞的处理方式。不过需要确保信息准确,不要混淆不同漏洞的细节。需要确认泛微E-Mobile的具体漏洞细节,可能查阅公开的漏洞分析文章或厂商公告。 可能用户是安全人员或系统管理员,需要评估自身系统是否受影响,并采取修补措施。因此,回答要提供明确的步骤,如检查版本号、应用补丁、配置安全策略等。同时,生成的相关问题可以涉及漏洞检测方法、修复后的验证步骤、类似漏洞的案例等。 最后,确保回答符合格式要求,使用中文,正确应用LaTeX,添加引用标识。可能需要检查是否有公开的泛微漏洞公告或安全公司的分析报告作为引用来源,比如引用[^1]中的内容,但需要确认是否与当前漏洞相关。如果引用不相关,可能需要调整或省略。</think>### 泛微E-Mobile messageType.do命令执行漏洞分析 #### 1. 测试背景 泛微E-Mobile是泛微OA系统的移动办公平台,提供移动端业务处理能力。2021年曝光的`messageType.do`接口命令执行漏洞(CVE编号未公开)属于高危漏洞,攻击者无需认证即可通过构造恶意请求在服务器执行任意系统命令[^1]。此漏洞主要影响历史版本(如6.0及更早版本),常见于未及时更新的企业内网系统。 #### 2. 漏洞成因 该漏洞源于以下设计缺陷: - **接口参数未过滤**:`messageType.do`接口的`messageType`参数直接拼接至系统命令 - **危险函数调用**:使用`Runtime.getRuntime().exec()`执行动态拼接的命令字符串 - **权限配置不当**:服务运行在高权限账户(如root/System)环境下 攻击示例(伪代码): ```java // 漏洞代码片段 String cmd = "echo " + request.getParameter("messageType"); Process proc = Runtime.getRuntime().exec(cmd); ``` #### 3. 技术分析 - **攻击向量**:通过注入`;`、`|`、`&&`等命令分隔符实现命令拼接 $$ \text{恶意参数} = \text{合法值} \, || \, \text{恶意命令} $$ - **利用特征**: ```http POST /messageType.do HTTP/1.1 messageType=1;whoami>/tmp/test ``` - **危害范围**:可导致服务器沦陷、数据泄露、内网渗透等 #### 4. 解决方案 | 措施类型 | 具体方案 | |---------|----------| | 紧急处置 | 1. 在WAF中添加规则拦截`messageType.do`的异常参数<br>2. 限制`/messageType.do`接口的访问IP | | 根本解决 | 1. 升级至官方修复版本(如V7.0+)<br>2. 修改代码实现参数白名单校验:<br>`if(!messageType.matches("[0-9]+")) { throw Exception; }` | | 安全加固 | 1. 降权运行服务进程<br>2. 部署RASP进行命令执行防护 | #### 5. 引用说明 [^1]: 该漏洞原理与常见Java应用命令执行漏洞模式相似,参考历史Java反序列化漏洞的防护思路(如CVE-2020-0688的输入验证机制)。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值