精华内容
下载资源
问答
  • 移动终端APP安全防护规范及安全开放标准解决方案。 包含:APP应用上线前安全评估原则、APP客户端安全功能要求、开发环境安全管理 、源代码的安全管理、委外开发安全要求等。
  • app安全评估操作指南手册,以及安全评估报告填写范例,开发者应用上架必备
  • 本文根据owasp出具的2016移动应用top10的checklist翻译而来,适用于所有android应用
  • 翻译自一位外国大牛的系列文章,共46篇,整理不易,内容详实,只提供给需要的人看。懂,请下载。
  • APP安全测试总结

    千次阅读 2018-05-16 11:42:57
    收集整理网上的资料以及自己测试过程中遇到的问题前言APP 安全一直是开发者头痛的事情,越来越多的安全漏洞,使得开发者越来越重视app安全,目前app安全主要有由以下几部分APP组件安全Android 包括四大组件:...

    收集整理网上的资料以及自己测试过程中遇到的问题

    前言

    APP 安全一直是开发者头痛的事情,越来越多的安全漏洞,使得开发者

    越来越重视app安全,目前app安全主要有由以下几部分

    APP组件安全

    Android 包括四大组件:Activitie、Service、Content Provider、Broadband Receiver, 
    它们每一个都可以通过外面隐式的Intent方式打开, 
    android组件对外开放 就会被其他程序劫持,因此必须在manifest里面声明 
    exported为false,禁止其他程序访问改组件, 
    对于要和外部交互的组件,应当添加一下访问权限的控制, 在有权限后外部程序才可以开启,或者提供特定的action过滤器达到启动目的。 
    还需要要对传递的数据进行安全的校验。不符合规则的一律不处理。

    Webview 安全漏洞

    Android API 4.4以前,谷歌的webview存在安全漏洞,网站可以通过js注入就可以随便拿到客户端的重要信息, 
    甚至轻而易举的调用本地代码进行流氓行为,谷歌后来发现有此漏洞后 
    ,在API 4.4以后增加了防御措施,如果用js调用本地代码,开发者必须在代码申明JavascriptInterface, 
    列如在4.0之前我们要使得webView加载js只需如下代码:

    mWebView.addJavascriptInterface(new JsToJava(), “myjsfunction”);

    4.4之后使用需要在调用Java方法加入@JavascriptInterface注解, 
    如果代码无此申明,那么也就无法使得js生效,也就是说这样就可以避免恶意网页利用js对客户端的进行窃取和攻击。

    APP反编译

    App被反编后,源码暴露,不仅对数据造成隐私泄露,而且对一些接口造成易攻击的潜在风险。 
    我们必须对apk进行源码混淆,并且进行apk加固

    APP二次打包

    即反编译后重新加入恶意的代码逻辑,或置入新病毒重新生成一个新APK文件。 
    二次的目的一般都是是盈利广告和病毒结合,对正版apk进行解包,插入恶意病毒后重新打包并发布,因此伪装性很强。截住app重打包就一定程度上防止了病毒的传播。因此app加固是防止二次打包的重要措施。

    APP进程劫持

    一般我们称为进程注入,也就动态注入技术,hook技术目前主流的进程注入方式,通过对linux进行so注入,达到挂钩远程函数实现监控远程进程的目的。

    APP DNS劫持

    DNS劫持俗称抓包。通过对url的二次劫持,修改参数和返回值,进而进行对app访问web数据伪装,实现注入广告和假数据,甚至起到导流用户的作用,严重的可以通过对登录APi的劫持可以获取用户密码,也可以对app升级做劫持,下载病毒apk等目的,解决方法一般用https进行传输数据。

    APP APi接口验签

    一般服务端的接口也会被攻击,虽然是服务端安全问题,但还是属于App系统维护体系,如果app后端挂了,app也不叫app了,一般变现为被恶意程序频繁请求某一接口,导致订单等重复注入,验证码被盗刷,虚假用户注册,严重的甚至拖垮app.

    今天先看下APP升级过程被劫持的问题

    我们做app版本升级时一般流程是采用请求升级接口,如果有升级,服务端返回下一个下载地址,下载好Apk后,再点击安装。 
    其实这个过程中有三个地方会被劫持。 请求升级时,下载文件时,安装时。

    • 升级APi

    升级Api建议用https,防止被恶意程序劫持,结果是恶意返回下载地址,这样就把伪装的apk下载到本地,结果你应该懂的!

    • 下载API:

      如果升级api你做了加固,下载api没做加固,还是徒劳,恶意程序也可以返回恶意文件或者apk,直到被你错误的安装在手机上。

      • 安装过程;

      假设你以上两个过程都做了加固,但是在安装apk的时候,本地文件path被错误修改了,仍然可以安装错误的apk,这不仅 
      会对用户体验产生不利,甚至会威胁手机安全。

    解决方案:

    • 升级api加入https 这个肯定不用再过多介绍,看了我介绍的retrofit 的https就明白了。

    • 下载Api也需加入https,也不用再做介绍,这里着重强调的是需要对服务端返回的文件进行Hash值校验,防止文件被篡改, 
      通过对文件hash值,还要对服务端返回的自定义key的进行校验验签,防止不是自己服务器返回错误的文件

    • 安装过程也必须对Apk文件进行包名和签名验证,防止Apk被恶意植入木马,或替换。

    假设我的升级bean为;

    public class UpgradeModel {
    
     private int code;
     private String msg;
    
     private DataBean data;
    
     public int getCode() {
        return code;
     }
    
     public void setCode(int code) {
        this.code = code;
     }
    
    public String getMsg() {
        return msg;
    }
    
    public void setMsg(String msg) {
        this.msg = msg;
    }
    
    public DataBean getData() {
        return data;
    }
    
    public void setData(DataBean data) {
        this.data = data;
    }
    
    public static class DataBean {
        private String description;
        private String downUrl;
        private String version;
        private String hashcod;
        private String key;
        private String isForce;
    
        public String getDescription() {
            return description;
        }
    
        public void setDescription(String description) {
            this.description = description;
        }
    
        public String getDownUrl() {
            return downUrl;
        }
    
        public void setDownUrl(String downUrl) {
            this.downUrl = downUrl;
        }
    
        public String getVersion() {
            return version;
        }
    
        public void setVersion(String version) {
            this.version = version;
        }
    
        public String getHashcod() {
            return hashcod;
        }
    
        public void setHashcod(String hashcod) {
            this.hashcod = hashcod;
        }
    
        public String getKey() {
            return key;
        }
    
        public void setKey(String key) {
            this.key = key;
        }
    
        public String getIsForce() {
            return isForce;
        }
    
        public void setIsForce(String isForce) {
            this.isForce = isForce;
        }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73
    • 74
    • 75
    • 76
    • 77
    • 78
    • 79
    • 80
    • 81
    • 82
    • 83
    • 84
    • 85
    • 86
    • 87
    • 88

    }

    通过一次请求到服务端数据后,如果有版本更新 我们应该先验证 
    Url和key是不是我们和服务端协商好的Url和key

     UpgradeModel  aResult = xxxx//解析服务器返回的后数据
    
     if (aResult != null && aResult.getData() != null ) {
    
            String url = aResult.getData().getDownUrl();
    
            if (url == null || !TextUtils.equals(url, "这里是你知道的下载地址: 也可以只验证hostUrl")) {
    
              // 如果符合,说明不是目标下载地址,就不去下载
    
            }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12

    接着我们验证下载url是你自己app的服务器地址,然后再去请求下载Api,这时用DownLoadModel接受请求头 ,看是否符合自己和服务器约定的key和hash之,下载好apk到本地后,继续判断文件的hash和升级api返回的hashcode, 加之key是否是和下载服务器返回的key,如果不一致,就不安装

          File file = DownUtils.getFile(url);
                // 监测是否要重新下载
         if (file.exists() &&   TextUtils.equals(aResult.getData().getHashCode(), EncryptUtils.Md5File(file))) {
          && TextUtils.equals(aResult.getData().getKey(), DownLoadModel.getData()..getKey())
    
          // 如果符合,就去安装 不符合重新下载 删除恶意文件
    
       }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    等我们验证了下载文件的地址是我们自己服务器提供的,验证没问题后就只剩安装了。接着还要对apk文件进行包名和签名校验,如果包名和签名不一致,那么就是伪装程序,这个漏洞显而易见!

    /** installApK
     * @param context
     * @param path
     * @param name
     */
    public static void installApK(Context context, final String path, final String name ) {
    
        if (!SafetyUtils.checkFile(path + name, context)) {
            return;
        }
    
        if (!SafetyUtils.checkPagakgeName(context, path + name)) {
            Toast.makeText(context, "升级包被恶意软件篡改 请重新升级下载安装", Toast.LENGTH_SHORT ).show();
            DLUtils.deleteFile(path + name);
            ((Activity)context).finish();
            return;
        }
    
        switch (SafetyUtils.checkPagakgeSign(context, path + name)) {
    
            case SafetyUtils.SUCCESS:
                DLUtils.openFile(path + name, context);
                break;
    
            case SafetyUtils.SIGNATURES_INVALIDATE:
    
                Toast.makeText(context, "升级包安全校验失败 请重新升级", Toast.LENGTH_SHORT ).show();
                ((Activity)context).finish();
    
                break;
    
            case SafetyUtils.VERIFY_SIGNATURES_FAIL:
    
                Toast.makeText(context, "升级包为盗版应用 请重新升级", Toast.LENGTH_SHORT ).show();
                ((Activity)context).finish();
                break;
    
            default:
                break;
        }
    
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43

    SafetyUtils安全类如下:

    /**
    * 安全校验
    * Created by LIUYONGKUI on 2016-04-21.
    */
    public class SafetyUtils {
    
        /** install sucess */
        protected static final int SUCCESS = 0;
        /** SIGNATURES_INVALIDATE */
        protected static final int SIGNATURES_INVALIDATE = 3;
        /** SIGNATURES_NOT_SAME */
        protected static final int VERIFY_SIGNATURES_FAIL = 4;
        /** is needcheck */
        private static final boolean NEED_VERIFY_CERT = true;
    
    /**
     * checkPagakgeSigns.
     */
    public static int checkPagakgeSign(Context context, String srcPluginFile) {
    
        PackageInfo PackageInfo = context.getPackageManager().getPackageArchiveInfo(srcPluginFile, 0);
        //Signature[] pluginSignatures = PackageInfo.signatures;
        Signature[] pluginSignatures = PackageVerifyer.collectCertificates(srcPluginFile, false);
        boolean isDebugable = (0 != (context.getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE));
        if (pluginSignatures == null) {
            PaLog.e("签名验证失败", srcPluginFile);
            new File(srcPluginFile).delete();
            return SIGNATURES_INVALIDATE;
        } else if (NEED_VERIFY_CERT && !isDebugable) {
            //可选步骤,验证APK证书是否和现在程序证书相同。
            Signature[] mainSignatures = null;
            try {
                PackageInfo pkgInfo = context.getPackageManager().getPackageInfo(
                        context.getPackageName(), PackageManager.GET_SIGNATURES);
                mainSignatures = pkgInfo.signatures;
            } catch (PackageManager.NameNotFoundException e) {
                e.printStackTrace();
            }
            if (!PackageVerifyer.isSignaturesSame(mainSignatures, pluginSignatures)) {
                PaLog.e("升级包证书和旧版本证书不一致", srcPluginFile);
                new File(srcPluginFile).delete();
                return VERIFY_SIGNATURES_FAIL;
            }
        }
        return SUCCESS;
    }
    
    /**
     * checkPagakgeName
     * @param context
     * @param srcNewFile
     * @return
     */
    public static boolean checkPagakgeName (Context context, String srcNewFile) {
        PackageInfo packageInfo = context.getPackageManager().getPackageArchiveInfo(srcNewFile, PackageManager.GET_ACTIVITIES);
    
        if (packageInfo != null) {
    
           return TextUtils.equals(context.getPackageName(), packageInfo.packageName);
        }
    
        return false;
    }
    
    /**
     * checkFile
     *
     * @param aPath
     *            文件路径
     * @param context
     *            context
     */
    public static boolean checkFile(String aPath, Context context) {
        File aFile = new File(aPath);
        if (aFile == null || !aFile.exists()) {
            Toast.makeText(context, "安装包已被恶意软件删除", Toast.LENGTH_SHORT).show();
            return false;
        }
        if  (context == null)  {
             Toast.makeText(context, "安装包异常", Toast.LENGTH_SHORT).show();
            return false;
         }
    
         return true;
     }
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39
    • 40
    • 41
    • 42
    • 43
    • 44
    • 45
    • 46
    • 47
    • 48
    • 49
    • 50
    • 51
    • 52
    • 53
    • 54
    • 55
    • 56
    • 57
    • 58
    • 59
    • 60
    • 61
    • 62
    • 63
    • 64
    • 65
    • 66
    • 67
    • 68
    • 69
    • 70
    • 71
    • 72
    • 73
    • 74
    • 75
    • 76
    • 77
    • 78
    • 79
    • 80
    • 81
    • 82
    • 83
    • 84
    • 85
    • 86
    • 87


    展开全文
  • 常见App安全问题

    千次阅读 2018-06-02 10:32:07
    常见的 App 安全问题据2015年第三季度移动安全报告显示,Android 16个行业 TOP 10 应用漏洞类别和数量中,Webview远程代码执行占到了第一位,第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域,我们所...

    常见的 App 安全问题

    据2015年第三季度移动安全报告显示,Android 16个行业 TOP 10 应用漏洞类别和数量中,Webview远程代码执行占到了第一位,第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域,我们所面临的漏洞是非常严峻的。

    常见安全问题分析

    上图可看出Android研发要点约450个,包含组建安全、配置安全、策略安全、通信安全、权限欧洲、DOS安全、ROOT安全等等,今天从这里面挑一些重点讲一下。

    组件安全问题。安全有四大原生的组建:

       一、Activity,首先是访问权限控制,组建处理不好会导致你的应用被恶意程序进行恶意的页面调用。作为研发人员,我们可以从以下三点来预防和避免这个问题:

    • 私有的Activity不应该被其他应用启动且应该确保相对是安全的;

    • 关于Intent的使用要谨慎处理接受的Intent,以及其携带的信息尽量不发送敏感信息,并进行数据校验。

    • 设置Android:exported属性,不需要被外部程序调用的组建应该添加android:exported=”false”属性。

       二、Service劫持、拒绝服务。

           常见的漏洞有 Java 空指针异常导致拒绝服务和类型转换异常导致的拒绝服务两种。应对 Service 带来的安全问题给大家三点建议:一我们应用在内部尽量使用 Service 设为私有,如果确认这个服务是自己私有的服务,就把它确认为私有,不要作为一个公开的服务;针对 Service 接收到的五数据应该进行校验;内部的Service需要使用签名级别的 protectionle。

    传输安全。本地校验用户验证码也非常重要,以后请大家开发中本地的数据校验尽量不要放在本地,尽量放在云端。对于数据的加密,建议所有的App和用户的客户端不要用一个共同的密钥,对于密钥生成的方法尽量根据用户的ID或者一些信息来生成出来,这样避免了大规模密钥的泄露。

    第三方组件安全。之前做App应用,在研发后对应用做了很多安全防御。但是大概刚上线不到两天就暴露出漏洞了,究其原因是App项目中用了国内一家非常著名的SDK的推送平台,由于这个平台在发送推送广播的时候没有做数据的校验,导致了黑客可以利用这个推送广播进行伪装,给我发一些数据,最后导致应用在接收了广播之后,只要我点击这个广播应用就崩溃。因此我们除了做好自身应用的安全以外,要保证所引用的第三方,或者合作伙伴也是安全的。也就是说安全是一个团队性的。

    Webview的代码执行漏洞。安卓存在一个非常著名的远程代码执行的漏洞,由于我们程序没有正确地使用,大家可能在做GS和Java户调的时候会遇到这个问题,远程攻击者可以通过Java分设接口执行一些恶意的Java方法,最终导致App在使用Webview的时候遭到攻击。我们是可以做一些应对的,安卓系统通过Webview通过一个注册来调用Java功能,攻击者利用反射对他进行攻击,其实谷歌也看到了这个问题,因为这个问题毕竟比较大、也比较广,所以谷歌在API Level17以后这个问题就得到了遏制,对于小于17,或者17以下的能不使用就不使用,如果真的要使用可以增加过滤,对数据的传输做一下校验。

    应用安全层。可以对代码进行一些混淆,如配置,如果觉得这还不够,也可以使用一些第三方的工具,比如APK文件。对于更加讲究安全性的经营类的企业,可以选择加固,使用脱壳程序,最后形成一个新的Dex包,最后完成对一个程序的加固。

    安全编码规范

    其实程序员的编码规范很重要。在Java中,对于一些重要的类、方法、变量,我们在定义的时候一定要想这么几个问题。

    • 定义的类或者变量到底返回什么?
    • 它们获得什么作为参数?
    • 是否能够绕过安全线?
    • 它是否含有能够绕过边界,从而绕过保护的方法变量?

    有了这种思想之后,对于一些安全性的风险代码为了防止暴露,我们可以做一些操作,说限制对变量的访问,让每个量的方法都成为Final,尽量使你的类不要被克隆,如果一旦允许被克隆,它可能会绕过这个类轻易地复制类的属性。安卓中很多会使用到序列化,如果自己觉得这个类是有风险的,或者说安全性是很高的,尽量不要让它序列化。最后是避免硬编码影响数据。

    黑无止境移动安全“漏洞”

    知道创宇高级安全顾问锅涛从攻击客的角度看看安全是怎么发生的,未来安全的主战场就在云这一块。未来移动市场肯定会成为我们整个生活的主角,因为移动是主角,就会对移动端安全信息的窃取,以及我们资产的窃取等,有主角的地方就有伤害。我们看到国外安全发展的趋势,尤其是国际上比较知名的Owasp。

    从黑客攻击的角度去分析未来攻击主战场,因为硬应用大家通过查阅书籍、网上、社区搜集资料都可以进行多方面的避免。但是黑客攻击的时候,发现攻击想要拿到的数据,就要去平衡一下攻击的成本,如果完全分析带来混淆,我就带来混淆防止别人能够快速分离出代码之间的逻辑。但是黑客也知道你做了大量比较,也就会换思路,就会从一个人的程序设计缺陷的漏洞利用,因为黑客最终是要拿到移动端和最终的核心数据库连接的信息,用户的信息,以及通过缺陷进行资产盗窃。黑客的攻击已经从一个应用发展到了一个逻辑。

    黑客在发动任何一次攻击的时候,都有成本。做防护就是为了增加黑客攻击的成本,无论是做代码混淆还是加固,成本提高了黑客有可能就会放弃攻击,但是他会寻找新的突破口。这就是下面要跟大家说的移动端里面业务逻辑设计缺陷,为什么业务逻辑设计缺陷会成为未来的一个主要的方向。

    • 应用逻辑是神一般地存在,老的程序员也是在劫难逃,因为业务的发展造成了程序员没法快速地去准备代码。
    • 安全开发人员也不能安全避免应用设计缺陷。
    • App本身的漏洞,一半的比例在业务漏洞上,而自己的逻辑漏洞没有一个自动化的程序促使全员去发现它。
    • 业务逻辑漏洞利用的就是开发人员本身人的缺陷,造成了它逃逸于各种防护,无论是代码混淆、加固等等。

    业务逻辑漏洞之所以会出现是因为业务发展迅速、开发水平不一、第三方缺陷、内部监管不严格也会出现这种漏洞发生。业务逻辑漏洞最常见的就是账号登陆限制的问题。还有安全性的问题,也会发现密码重置,还有的是采用手机号+我的验证码,就造成了黑客可以利用验证码进行破解,以及常见的另一种安全问题是App端的客户端应用。

    随着我们业务的发展,发现在金融行业,以及在我们的社交领域另一种手势密码。手势密码安全其实还是可以的,但是手势密码有很多解锁,可以通过多种方式去对手势密码进行一个修改。最常见的有暴力破解,以及去修改这一个文件重置本地手势密码。



    展开全文
  • APP安全测试小技巧

    千次阅读 2020-03-27 18:53:17
    APP安全测试小技巧---证书校验绕过 随着移动互联网的快速发展,很多业务已转移到移动端进行运营,随之而来的就是移动端的安全问题,在早期移动互联网刚刚兴起的时候,很多APP没有重视安全问题,故而没有进行一定的...

    APP安全测试小技巧---证书校验绕过

    随着移动互联网的快速发展,很多业务已转移到移动端进行运营,随之而来的就是移动端的安全问题,在早期移动互联网刚刚兴起的时候,很多APP没有重视安全问题,故而没有进行一定的防护,换而言之就运行在手机端的web程序,所以早期安全测试很简单,也很容易发现问题(这里不讨论漏洞问题,只是介绍一个测试小技巧)。

    常用的web安全测试往往会借助Burpsuite这个神器进行测试,主要抓包分析。相信很多搞安全的同学都知道APP的抓包方式和流程,这里不多赘述了,抓取http的数据包很容易,但是抓取https数据包时就犯难了,因为经常会遇到SSL Pinning导致测试遇到瓶颈,网上有很多办法可以绕过,例如:

    1. Xposed+JustTrustMe;
    2. 使用Frida绕过;
    3. 其他...(我目前只用过这两个,因为懒)

    但是以上很多方法往往需要手机要有root权限,而且过程较为复杂。这里演示抓包失败的例子:

    1、在APP内安装证书,并设置好代理;

    2、对有做证书校验的APP进行测试,Burpsuite开启抓包时,会提示抓不到,并且APP会进行相应的提示。

    使用小技巧(主要通过挂代理,不是直接抓APP的数据包)进行测试,例子如下:

    1、开启Burpsuite的代理;

    2、开启代理软件proxifier,设置对应的代理服务器和代理规则

    需要注意选对应用程序!!!!

    3、取消APP上的代理但是要注意仍需安装证书,可以通过APP的文件助手进行安装。

    3、可以成功抓取https数据包

    以上技巧在一个“养猫博主”指导下完成,仅供参考,有任何疑问请私聊(QQ:1049180739 记得备注来意)

    展开全文
  • iOS APP 安全测试

    千次阅读 2020-05-08 14:25:14
     首先,我们可以通过iTunes 下载 AppStore的ipa文件(苹果 把开发者上传的ipa包 进行了加壳再放到AppStore中),所以我们从AppStore下载的ipa都是加壳的,所以不能直接用来反编译。  得到ipa文件 可以分析APP 里...

     

    1、ipa包加壳

      首先,我们可以通过iTunes 下载 AppStore的ipa文件(苹果 把开发者上传的ipa包 进行了加壳再放到AppStore中),所以我们从AppStore下载的ipa都是加壳的,所以不能直接用来反编译。

      得到ipa文件 可以分析APP 里包含的一些资源,如:图片、plist文件、静态wap页、.bundle 等。

      所以不要 在plist文件、项目中的静态文件中 存储关键的信息,如果要保存,记得 对称加密(这样可以增加破解的难度)。

      如果是越狱的手机,从 手机上的PP助手下载的ipa包 都是 脱壳之后的,可以直接用来反编译。

     

    2、敏感信息存储位置

      我们可以用软件 查看 APP的沙盒,查看里面存储的 文件:sqlite、plist(NSUserdefault会存到Library下的Preferences中 的 plist文件中)、图片等,NSUserdefault 中不要保存关键信息,如果要保存,还是加密吧。。sqlite也是这样子的。

      iOS 8.3之前 不越狱的手机也可以 直接用MAC上的PP助手、iTool 来查看 任何APP的沙盒(系统APP除外)。iOS 8.3之后就不行了。

      越狱手机都可以查看任意APP的沙盒,包括系统APP的沙盒。还有iOS的系统目录等。

     

    3、设备安全(越狱,丢失)

      越狱手机直接用PP助手下载的就是 脱壳的ipa,所以不用再脱了。对AppStore下载的ipa包 可以用工具对加壳的ipa 进行脱壳,再用IDA、Hopper 进行反编译,进行分析 ,可以得到 近乎易懂的 伪代码。但是反编译后的代码 要 一个方法一

    展开全文
  • ANDROID APP安全入门概述 技术创新变革未来 目录 1 APP安全初探 2 APP安全学习路径 3 一点体会 APP安全初探 Part 1 APP 安全现状 数据来源2019金融行业移动APP安全观测报 数据来源工业和信息化部华经产业研究院 告 ...
  • 移动APP安全测试

    千次阅读 2018-11-06 16:07:34
    1 移动APP安全风险分析 1.1 安全威胁分析 安全威胁从三个不同环节进行划分,主要分为客户端威胁、数据传输端威胁和服务端的威胁。 1.2 面临的主要风险 1.3 Android测试思维导图   1.4 反编译工具 ...
  • 移动APP安全测试要点

    万次阅读 2018-08-02 15:46:44
    安全检测要点 Allowbackup漏洞 WebView漏洞 关键数据明文传输 任意账号注册 登录界面可被钓鱼劫持 有争议的整改建议 关键数据明文传输 登录界面钓鱼劫持 总结 评估思路 移动APP面临的威胁 ...
  • APP安全性测试

    千次阅读 2017-11-21 21:34:44
     随着互联网发展,APP应用的盛行,最近了解到手机APP相关的安全性测试,以webview为主体的app,站在入侵或者攻击的角度来讲,安全隐患在于http抓包,逆向工程。  目前大部分app还是走的http或者https,所以防http...
  • 2014 年初,移动互联网产业快速发展,App 井喷式爆发,绝大多数使用的是 Android 系统。但是那时候大多数的开发者没有做好 App安全防护措施,面对移动互联网黑灰产的攻击,...
  • app安全评估报告,如何搞定呢?!

    万次阅读 2019-06-19 06:40:39
    你的app上架,遇到【安全评估报告】门槛了么?什么是“安全评估报告”?没有“报告”会有什么后果?专业的第三方评测机构帮助企业app顺利上架 什么是“安全评估报告”? 2018年11月15日,网信办...
  • 五大APP安全在线检测平台对比

    千次阅读 2019-03-13 18:06:06
    五大APP安全在线检测平台对比 时间2017-10-31 标签APP自动化检测Android安全移动安全ios安全栏目系统安全 原文http://1425831735.blog.51cto.com/12166228/1977785 Android APP检测之自动化检测实战:五大APP...
  • 移动安全-APP安全加固

    千次阅读 2019-08-04 17:03:56
    App防止反编译 被反编译的暴露客户端逻辑,加密算法,密钥,等等 加固 Java层代码源代码反编译风险 被反编译的暴露客户端逻辑,加密算法,密钥,等等 加固 ,混淆 so文件破解风险 导致核心代码泄漏 so文件加固 ...
  • 常见的 App 安全问题

    万次阅读 2016-12-23 15:32:36
    常见的 App 安全问题 据2015年第三季度移动安全报告显示,Android 16个行业 TOP 10 应用漏洞类别和数量中,Webview远程代码执行占到了第一位,第二位是Webview文明存储密码。这些领域涵盖大家平时工作领域,我们...
  • Android APP安全测试

    千次阅读 2018-03-17 21:14:21
    移动APP面临的威胁:木马、病毒、钓鱼、破解、篡改、二次打包、账号窃取、广告植入、信息劫持等一、Android APP安全测试思路分析:1.安全测试工具2.基础环境3.数据安全4.程序安全5.数据传输6.业务安全二、APP面临的...
  • APP安全漏洞学习笔记

    千次阅读 2016-12-28 21:46:16
    APP安全漏洞学习笔记 本文首先明确了APP安全的目标,然后对常见的APP漏洞进行了整理分析,并研究学习了APK的静态分析与动态分析技术,最后介绍了安卓的渗透测试技术和常见的安全评估工具。附录处整理了2014年和...
  • iOS app安全技术总结

    万次阅读 2018-02-14 09:54:33
    iOS app安全技术总结 很多开发者认为,iOS系统的封闭性使APP更加安全。事实上,根据国外某安全服务商的最新调查显示:iOS前100名的付费应用中有87%均遭黑客破解。内购破解、源代码破解、本地数据窃取等,为iOS应用...
  • Android hook原理及APP安全

    千次阅读 2019-08-18 13:34:29
    如何保证APP安全。 这篇文章不对逆向和hook进行分析,如有不知道的,请看我之前的文章。 原理: 通过替换/system/bin/app_process程序控制zygote进程,使得app_process在启动过程中会加载XposedBridge.jar这个...
  • 免费的APP安全在线检测平台

    千次阅读 2020-04-25 11:04:19
    提供APP免费加密、免费检测服务,可在线查看检测详情,下载安全检测报告。 https://www.ijiami.cn/index 2、梆梆安全 开发者服务平台提供免费检测和加固,并且提供的桌面级(PC端)APP加固辅助工具。 ...
  • Android App 安全登录认证解决方案

    万次阅读 多人点赞 2018-03-07 17:16:59
    基于Android App 安全登录认证解决方案近几年移动互联网的高速发展,智能手机的使用用户呈现爆炸性增长,手机终端上的App 种类繁多,大多数App 都需要与后台系统进行交互,交互的第一步需要进行登录认证,过于简单的...
  • APP安全在线检测--持续更新

    万次阅读 2018-04-01 09:47:50
    伴随着移动互联网的高速发展,移动应用APP的安全问题也走进了人们的视角,在企业安全建设过中,往往需要对企业移动应用APP进行一个安全风险评估,从而了解总体的安全情况,以下我们将简要介绍以下的几个APP安全在线...
  • App安全之网络传输安全问题

    千次阅读 2016-09-29 15:22:26
    App安全之网络传输安全问题 字数4865 阅读132 评论1 喜欢1 App安全之网络传输安全问题 移动端App安全如果按CS结构来划分的话,主要涉及客户端本身数据安全,Client到Server网络传输的安全,客户端本身...
  • app安全测试你知道多少

    千次阅读 2018-08-02 15:37:51
    目录 一、安装包测试 1.1、关于反编译 1.2、关于签名 1.3、完整性校验 ...目的是为了保护公司的知识产权和安全方面的考虑等,一些程序开发人员会在源码中硬编码一些敏感信息,如密码。而且若程序内部一...
  • ANDROID APP安全从入门到放弃 照片部分由主办方添加 何勇亮 上海市信息安全测评认证中心 WHO AM I 高级等保测评师 CISPCISSPCISAWPMP 等级保护测评渗透测试 网络安全咨询风险评估 Wechat unicotech 目录 1 APP安全...
  • iOS APP安全杂谈之二

    千次阅读 2015-12-24 18:26:45
    0x00 序 ...自从上一篇文章发了以后,参加乌云众...但是我依然感到幸运,因为今天可以为IOS APP安全杂谈写个续集。 上一节我们主要说了三点:IOS APP本地文件安全;HTTP/HTTPS下通信数据安全性的思考;非安全从

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 406,799
精华内容 162,719
关键字:

app安全