1***@qq.com
1***@qq.com
  • 发布:2020-06-30 15:01
  • 更新:2021-07-03 17:46
  • 阅读:2645

iOS云打包等保漏洞的注入攻击风险和不安全的API函数引用风险

分类:uni-app

等保测评,一堆问题,安卓倒是可以加固解决大部分,暂且不提。
苹果的检测报告就两个问题,
2.1.12. 注入攻击风险
测评目的 检测ipa包是否存在注入攻击风险
危险等级 高
危害 攻击者通常有两种手段进行攻击,第一种是修改app的二进制文件增加攻击代码,第二种是通过注入外部库,即启动前通过设置DYLD_INSERT_LIBRARIES环境变量指定第三方库文件,加载前会优先加载第三方库文件。攻击者可以通过注入攻击将一段恶意代码写到目标进程,这段代码可以加载其它可执行程序,进而实施hook,监控程序运行、获取敏感信息等。常见的动态注入,可以实现窃取输入的登录账号、密码、支付密码,修改转账的目标账号、金额,窃取通讯数据等。
测评结果 存在风险(发现1处)
测评结果描述 该App中存在注入攻击风险
测评详细信息

解决方案 开发者自查:xcode设置Other Linker Flags,参数增加
-Wl,-sectcreate,RESTRICT,restrict,/dev/null

2.1.13. 不安全的API函数引用风险
测评目的 检测iOS App程序中是否引用了不安全的系统API函数
危险等级 高
危害 iOS中提供的系统API函数中,包含一些存在安全隐患或者需配合指定方式使用的系统API,否则将会导致安全性问题。其中,比较明显的一种问题就是缓冲区溢出攻击。此类API中无法自动对栈中的数组进行边界检查,而且局部变量和状态信息,都存在栈中。这样,对越界的数组元素的写操可能会破坏存储在栈中的状态信息。当程序使用这个被破坏的状态,试图重新加载寄存器或执行ret指令时,就会出现很严重的错误,可能导致程序运行失败、系统关机、重新启动。更加致命的情况是让程序跳转去执行攻击者的恶意指令,比如非法提升权限,执行恶意代码等。
测评结果 存在风险(发现6处)
测评结果描述 该App程序中引用了不安全的系统API函数
测评详细信息 313532 0x0113037f 0x0113437f 10 11 ascii &@_getenv
313852 0x01132313 0x01136313 10 11 ascii &@_sscanf
313806 0x01131e00 0x01135e00 11 12 ascii &@_sprintf
313918 0x011328da 0x011368da 12 13 ascii &@_vsprintf
313856 0x01132359 0x01136359 10 11 ascii &@_strcat
313859 0x0113238c 0x0113638c 10 11 ascii &@_strcpy

解决方案 开发者移除应用程序中调用的系统风险函数和过期api,同时防止系统直接调用存在C缓冲区溢出的函数如 memcpy、scanf、sprintf、strcpy、vsprintf

请问官方大大有没有人帮忙康康、

2020-06-30 15:01 负责人:CLP 分享
已邀请:
CLP

CLP

这是哪个公司还是机构的检查结果吗?

  • 1***@qq.com (作者)

    是的,iOS安全风险已经降级处理,目前有一个sqlite注入风险,建议不让使用sql拼接,但是我看sqlite并没有类似?的处理方式吧,sql参数如果是数组会作为多个语句执行,只能是多加校验吗?但是这样不能过等保啊。

    2020-07-02 20:08

  • CLP

    回复 1***@qq.com: 是哪家公司或者机构,叫啥名? 描述的那2个风险是误报吧,使用sprintf这些怎么就有风险了

    2020-07-02 20:12

  • CLP

    sql语句现在支持的是字符串,可以多个语句拼在一起。你说的不拼接具体是什么意思?

    2020-07-02 20:18

  • 1***@qq.com (作者)

    回复 CLP: 开发者自查:不要拼接SQL,可以换为executeSql(“SELECT name FROM stud WHERE id=?“, [input_id]);)以上是对方给出来的解决方案,对方扫到我们的一些js代码有“plus.sqlite.executeSql”字样,让我们不要拼接sqlite

    2020-07-02 20:22

  • 1***@qq.com (作者)

    回复 CLP: 哪家机构就不知道了,客户去第三方做的等保测评。

    2020-07-02 20:23

  • CLP

    回复 1***@qq.com: 换成占位的方式就没风险了?

    2020-07-02 20:49

  • 1***@qq.com (作者)

    回复 CLP: 人家评估报告是这么写的,非要抓住不放,我们也想有没有什么好的理由去说服他们,或者您能给出合理的解释我们这么写的风险不高嘛

    2020-07-02 20:58

  • 矮子古斯曼

    回复 1***@qq.com: 老哥 2.1.13. 不安全的API函数引用风险 最后你咋解决的? 我这边也检查出来 完全没法查啊

    2020-07-16 16:41

  • 1***@qq.com (作者)

    回复 矮子古斯曼: 这就不是代码层面的了,去找甲方或者第三方谈吧。

    2020-07-16 16:44

  • 矮子古斯曼

    回复 1***@qq.com: 是因为第三方.a文件调用吗? 最后是怎么解决的?能咨询下吗

    2020-07-17 10:40

  • 疯菜莱莱

    回复 1***@qq.com: App程序中是否引用了不安全的系统API函数 这个问题,大佬后面怎么解决的?

    2020-08-24 18:31

  • 你们123

    回复 疯菜莱莱: 这个最后解决了吗

    2020-12-17 18:18

  • 你们123

    回复 矮子古斯曼: 这个最后你是怎么解决的

    2020-12-17 18:18

炒饭包子

炒饭包子

请问这两个问题后续是如何解决的?

  • CLP

    请重新开个帖子,把问题描述清楚

    2021-07-07 15:13

要回复问题请先登录注册