Shared storage cannot protect your application from code injection attacks

本文介绍了从Android 4.1.2开始,由于安全限制,应用程序无法直接从sdcard加载字节码的问题及解决方法。文章详细解释了异常产生的原因,并提供了一种解决方案:将dex文件放置于应用自身的缓存目录中进行加载。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在动态加载dex的时候可能会出现以下问题:

 java.lang.IllegalArgumentException: Optimized data directory /storage/emulated/0 is not owned by the current user. Shared storage cannot protect your application from code injection attacks.


原因:

从Android4.1.2开始,App不能直接从sdcard中加载字节码,因为sdcard对于所有应用程序来说是共享的,为了防止恶意的代码注入,当采用DexClassLoader从sdcard中动态加载字节码的时候,就会抛出异常,为了安全,在DexFile下加入了以下代码判断

Libcore.os.getuid() != Libcore.os.stat(parent).st_uid

用来判断两个程序是不是同一个uid


DexFile:

private DexFile(String sourceName, String outputName, int flags) throws IOException {
        if (outputName != null) {
            try {
                String parent = new File(outputName).getParent();
                if (Libcore.os.getuid() != Libcore.os.stat(parent).st_uid){
                    throw new IllegalArgumentException("Optimized data directory " + parent
                            + " is not owned by the current user. Shared storage cannot protect"
                            + " your application from code injection attacks.");
                }
            } catch (ErrnoException ignored) {
                // assume we'll fail with a more contextual error later
            }
        }
 
        mCookie = openDexFile(sourceName, outputName, flags);
        mFileName = sourceName;
        guard.open("close");
        //System.out.println("DEX FILE cookie is " + mCookie);
    }


解决方法:

指定dexoutputpath为APP自己的缓存目录,通过context.getDir(“dex”,0)。作为dex的加载目录。

也就是用app的私有目录,data/data/应用程序包名下创建一个dex目录放置该dex,并作为加载目录。

加入以下代码即可:

File dexOutputDir = context.getDir("dex", 0);

DexClassLoader loader= new DexClassLoader(dexpath, dexOutputDir.getAbsolutePath(), null, ClassLoader.getSystemClassLoader().getParent());





### Injection Attacks 的定义和相关概念 Injection Attacks(注入攻击)是一种常见的网络安全威胁,攻击者通过将恶意代码或数据注入到系统中,利用系统的漏洞来执行非预期的操作。这类攻击的核心在于利用输入验证不足或处理不当的系统,使得恶意代码能够在目标环境中被执行。 #### 定义 注入攻击通常发生在应用程序未能正确过滤用户输入的情况下。攻击者可以通过向系统输入恶意代码或命令,使系统将其误解为合法输入并执行。这种攻击可能导致数据泄露、系统控制权丢失或服务中断等问题[^1]。 #### 常见类型 以下是几种常见的注入攻击类型: 1. **SQL Injection (SQL注入)** SQL 注入是最常见的注入攻击之一,攻击者通过在输入字段中插入恶意 SQL 语句,篡改数据库查询逻辑,从而获取敏感信息、修改数据或删除数据[^2]。 2. **Cross-site Scripting (XSS) Attacks (跨站脚本攻击)** XSS 攻击涉及将恶意脚本注入到网页中,当其他用户访问该页面时,脚本会在他们的浏览器中执行。这种攻击常用于窃取用户会话信息或执行未经授权的操作[^2]。 3. **Command Injection (命令注入)** 命令注入攻击利用应用程序未正确过滤用户输入的情况,将恶意命令注入到操作系统命令中。攻击者可以借此执行任意系统命令,可能危及整个服务器的安全性。 4. **Prompt Injection Attacks** Prompt Injection 是一种针对大型语言模型(LLMs)的新型攻击方式。研究者发现,通过设计特定的触发器(如“前缀+后缀”格式的字符串),可以迫使 LLM 忽略原始任务并执行注入的恶意指令[^5]。 5. **Data Poisoning Attacks (数据投毒攻击)** 数据投毒攻击是指攻击者通过污染训练数据集,在模型中植入后门或影响其预测输出。例如,在 NLP 领域中,攻击者可以通过在训练数据中添加特定模式的样本,使模型在遇到这些模式时产生错误预测[^3]。 #### 示例代码:SQL Injection 以下是一个简单的 SQL 注入示例,展示了攻击者如何通过构造恶意输入绕过身份验证: ```python # 用户输入的恶意 SQL user_input = "' OR '1'='1" query = f"SELECT * FROM users WHERE username = '{user_input}' AND password = 'password'" print(query) ``` 上述代码生成的查询语句将始终返回 `True`,导致攻击者无需密码即可登录系统[^2]。 #### 防护措施 为了防止注入攻击,开发者应采取以下措施: - 对所有用户输入进行严格的验证和清理。 - 使用参数化查询或预编译语句以避免直接拼接用户输入。 - 实施最小权限原则,限制应用程序对数据库或其他资源的访问权限[^4]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值