Electron(nodejs)桌面应用安全性checklist,桌面应用安全测试

本文讲述了Electron(nodejs)桌面应用安全性checklist,桌面应用安全测试。

关于electron

electron是chromium和nodejs的组合，主要使用了chromium的浏览器功能，并使用nodejs扩展了其文件系统访问、命令执行等功能。

由于使用的是chromium的content模块（渲染库），而不是完整的浏览器，所以同源策略需要electron自行控制；而且其扩展功能更需要仔细过滤及控制

安全性checklist

一、定时更新electron，包括chromium和nodejs模块

因为electron自身还在高速迭代中，会不断修复很多安全性bug

二、禁用nodeIntegration（重要）

启用nodeIntegration即开启nodejs扩展功能；electron APP界面一般是BrowserWindow和webview标签，都是用来加载html页面的。

若开启nodeIntegration，在html页面中可以执行命令<img/src=x οnerrοr="require('child_process').exec('gnome-calculator')">打开计算器

不建议加载远程不安全的html页面，因为即使禁用了node，默认也是可以访问file域，造成数据泄露

加载可信页面，要注意用户交互产生的XSS，因为结合node的强大功能，xss可以造成命令执行

三、使用https，并保证证书校验（重要）

排查allowRunningInsecureContent属性，排查是否忽略证书错误.on('certificate-error', 和.setCertificateVerifyProc(，及导入证书.importCertificate(

四、使用sandbox属性

虽然禁用了nodeIntegration，还有一些扩展API是暴露的，比如 window.open返回的BrowserWindowProxy。使用sandbox属性会禁止这些扩展API，但进程间通信受到了限制（具体见开发文档）

BrowserWindow支持sandbox属性，webview暂不支持

五、审查preload脚本，启用contextIsolation属性

preload脚本会无视nodeIntegration和sandbox，排查BrowserWindow的preload 的javascript脚本是否启用contextIsolation（类似chrome插件机制）

六、过滤命令行参数

比如设置代理功能和开启调试功能，排查appendArgument、appendSwitch、proxy-server、–debug

七、检测危险网站

监听跳转事件.webContents.on('will-navigate',，过滤危险网址。最好使用外部浏览器打开

八、监听权限请求事件

 geolocation,打开弹窗等权限，必须实现.setPermissionRequestHandler(，否则外部网址可以恶意使用。若使用外部浏览器打开链接，则不需要关心

九、慎用insertCSS, executeJavaScript、eval、openExternal函数

十、禁止popups

webview的allowpopups可以打开新window，默认是禁止的

十一、检测自定协议

setAsDefaultProtocolClient

• registerStandardSchemes

• registerServiceWorkerSchemes

• registerFileProtocol

• registerHttpProtocol

• registerStringProtocol

• registerBufferProtocol

十二、启用CSP

同浏览器CSP，搜索webRequest.onHeadersReceived实现，或meta标签中

十三、-并打开可执行文件（重要）

-可执行文件，建议对其重命令，或只提供打开所在文件夹功能，避免打开文件之后执行命令

使用工具扫描

源码一般存在app.asar中，安装asar工具解包app.asar文件，然后使用electronegativity扫描源码

调试工具

https://github.com/bytedance/debugtron

抓包测试

如果APP使用net/http模块，不能使用fiddler等抓包，需使用wireshark；如果使用chromium的ajax等，则可以用fiddler抓包

App启动时间

冷启动：当启动应用时，后台没有该应用的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就是冷启动

启动app命令：adb shell am start -W -n package/activity

停止app命令：adb shell am force-stop package

获取运行app包名：adb logcat | grep START

热启动：当启动应用时，后台已有该应用的进程(例：按home键回到桌面，但是该应用的进程是依然会保留在后台，可进入任务列表查看)，所以在已有进程的情况下，这种启动会从已有的进程中来启动应用，这个方式叫热启动

启动app命令：adb shell am start -W -n package/activity

停止app命令：adb shell input keyevent 3

CPU

查看cpu的资源占用

Mac下：adb shell dumpsys cpuinfo | grep packagename

Windows下：adb shell dumpsys cpuinfo | findstr packagename

内存

获取app进程ID：adb shell ps | findstr packageName

查看App内存的占用：adb shell top -n 1 -d 5 | findstr pid(进程ID)

流量

获取进程ID指令：adb shell ps | grep packagename

查看Android 设备的网卡信息：adb shell netcfg

查看所有网卡流量：adb shell cat /proc/pid/net/dev

获取进程ID网卡流量：adb shell cat /proc/ pid /net/dev | findstr wlan0

电量

设置手机为非充电状态：adb shell dumpsys battery set status 1

查看电量的使用情况：adb shell dumpsys battery |findstr level

App在大量的用户那里被安装和使用的时，没有预料的问题

Crash的问题

设备兼容性的问题

流量使用过多的问题

App导致用户手机电量消耗过快的问题

在不同的网络情况下不稳定，比如卡死和白屏的问题

兼容性测试

针对App通常会考虑这些方面

操作系统版本：Andoird版本和iOS版本

屏幕分辨率：不同厂家的ROM

网络类型：比如Wifi、3G、4G下的功能情况

流量测试

在移动产品的测试中，很有必要对App使用的流量进行度量，大致来说，流量可以从用户使用的的相关性角度分为：一类是用户的操作直接导致的流量消耗；另一类是后台，即在用户没有直接使用情况下的流量消耗

步骤一：找到当前APP的进程号，shell模式下执行【ps -ef | grep 程序包名】

步骤二：shell模式下执行【cat /proc/进程号/net/dev 】

电量测试

在木器电池技术没有取得巨大突破前提下，这方面始终会存在一些瓶颈，如果一些App架构设计的不好，或者代码偶缺陷，就可能导致电量消耗比较高，所以电量测试也是很重要的

切换手机电池为非充电状态adb shell dumpsys battery set status 1

改变手机电量

让手机电量显示百分百： adb shell dumpsys battery set level 100

让手机电量显示1： adb shell dumpsys battery set level 1

弱网络测试

移动互联网产品相比PC互联网产品，有一个特点是前者使用的网络比较多样，除了Wif之外，很多时候是在移动网络下使用的，移动网络遇到的情况又比较复杂，比如地铁、隧道、体育场等。所以网络不稳定的情况是比较容易发生的，很多情况下App的一些问题是在复杂的网络情况下才会暴露，与其让用户发现和投诉这些问题，不如我们在测试阶段尽量模拟这样的网络情况，及早发现和修复这些问题

问题/原因

场景一

场景：上传大图或者多图时，在弱网络环境下出现进度条走到一半卡住然后又从头开始

原因：采用分段上传方式，在请求超时时间到时，分段传输没有结束，代码逻辑不对，导致每次重试都重头上传，一直循环

场景二

场景：在弱网络环境下容易出现登录不上

原因：登录没有缓冲机制，而请求超时时间的设置没有区分同网络情况；解决方案：针对wifi、2g、3g、4g设置不同的超时时间

场景三

场景：刷新页面很快就给出暂无内容的提示，明显没有到请求超时时间

原因：可能是连接超时时间太短，wifi下设置两秒，在弱网络下需要加长

场景四

场景：弱网络环境下，请求的数据返回时间较长，等待的过程中，如果页面上的相关控件仍然可以操作，则有可能出现闪退现象

原因：依赖数据的控件操作，在数据返回前没有做兼容处理

场景五

场景：搜索时输入关键字会连续发请求，停下时，显示最终的关键字搜索结果，但很快又会被前面的关键字搜索结果覆盖了

原因：中间的请求返回较慢，显示了最终的结果后，之前的请求返回的数据应不做处理

稳定性测试

在保证基本功能正确基础之上，App的稳定性就显得非常重要，如果一个App经常出现闪退或者卡死，那么用户体验就会受到很大伤害，在有其他竞争产品的情况下很容易造成用户的流失

安全测试

包括安装包的安全测试(能否反编译代码、安装包是否签名等)、敏感信息测试、软键盘劫持、账户安全、数据通信安全等。服务器端的SQL注入测试、XSS跨站脚本攻击等

环境相关的测试

在实际项目中，有一些缺陷我发现是和App所处的运行环境相关的，所以设计测试的时候，要多考虑这些场景。

干扰测试:收到电话、收到短信、收到通知栏消息、无电提示框弹出、第三方安全软件告警弹出

权限测试:一些用户在实际使用App的时候会有意识阻止某些功能。例如有的用户感觉让某个App访问电话本或者相册可能泄漏隐私，就在手机中设置了禁止了该App访问相册的权限

边界测试:

手机环境本身也有其边界情况需要在测试中覆盖。常见的场景有：可用存储空间过少、没有SD卡/双SD卡、飞行模式、系统时间有误(晚于和早于标准时间)、第三方依赖(比如我们的App依赖第三方App，但是现在第三方App没有安装或者版本过低的测试情况)

adb shell top -m 5 -n 6 -n 5

显示前5个进程，刷新6次，间隔5秒

-m 最多显示多少个进程

-n 刷新次数

-d 刷新间隔时间(默认5秒)

PID 进程id

PR 优先级

CPU% 当前瞬时CPU占用率

S 进程状态:D=不可中断的睡眠状态, R=运行, S=睡眠, T=跟踪/停止, Z=僵尸进程

#THR 程序当前所用的线程数

VSS Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)

RSS Resident Set Size 实际使用物理内存(包含共享库占用的内存)

PCY 调度策略优先级，SP_BACKGROUND/SP_FOREGROUND

UID 进程所有者的用户id

Name 进程的名称

压力测试

--throttle 设置每次随机事件的时间间隔(单位：毫秒)

例：adb shell monkey 100 --throttle 500

CPU测试中的测试子项

空闲状态下的应用CPU消耗情况

中等规格状态下的应用CPU消耗情况

满规格状态下的应用CPU消耗情况

应用CPU峰值情况

内存测试中的测试子项

空闲状态下的应用内存消耗情况

中等规格状态下的应用内存消耗情况

满规格状态下的应用内存消耗情况

应用内存峰值情况

应用内存泄露情况

应用是否常驻内存

压力测试后的内存使用情况

内存问题现象

ü 内存抖动

ü 大内存对象被分配

ü 内存不断增长

ü 频繁GC

名词解释

VIRT:virtual memory usage 虚拟内存

ü 进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据等

ü 假如进程申请100m的内存，但实际只使用了10m，那么它会增长100m，而不是实际的使用量

RES:resident memory usage 常驻内存

ü 进程当前使用的内存大小，但不包括swap out

ü 包含其他进程的共享

ü 如果申请100m的内存，实际使用10m，它只增长10m，与VIRT相反

ü 关于库占用内存的情况，它只统计加载的库文件所占内存大小

SHR:shared memory 共享内存

ü 除了自身进程的共享内存，也包括其他进程的共享内存

ü 虽然进程只使用了几个共享库的函数，但它包含了整个共享库的大小

ü 计算某个进程所占的物理内存大小公式：RES – SHR

ü swap out后，它将会降下来

上文就是小编为大家整理的Electron(nodejs)桌面应用安全性checklist,桌面应用安全测试。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。