前言
最近，很多学校都引入了智慧课堂系统，比如我所在的学校。智慧课堂系统在学习上的用处暂且不论，但是我也发现，智慧课堂系统也同时会造成计算机安全问题。
本文将从智慧课堂系统的角度浅谈计算机安全。
存在的问题
1、使用未经加密的通道传输关键信息
我注意到，该智慧课堂系统在传输数据时是未经加密的。例如，使用HTTP协议传输更新指令、个人信息甚至登录信息（如密码、设备序列号等）。这无疑严重危害信息安全。
然而令人费解的是，该系统大部分数据都使用了HTTPS协议，唯独api.xxxx.cn（注：xxxx.cn是该系统官网的域名）（注：从api这个前缀就知道它多重要了）却使用HTTP协议（甚至连Let’s Encrypted的免费证书都不愿申请）。为何系统开发者却没有看到？但凡一个程序员看到这个大大的 http:// 都不至于出现这种情况。
即使是这样，该系统在登录时都明文传输密码等关键信息，令人费解。
2、获取重要信息前未经鉴权
某天系统更新后，该系统的平板中新安装了名叫“XX桌面”的桌面应用，代替了系统原有的桌面。同时，系统“安全与屏幕保护”设置项中，屏幕锁定方式也只能选择“无”或“滑动”。替代原有锁屏的，是XX桌面的新功能“手势锁屏密码”。
设置手势锁屏密码后，每次解锁，XX桌面都会要求输入正确的手势，或使用系统的登录密码解锁。
这看起来很安全，然而，根据我抓包发现，该桌面会上传手势密码至服务器（这次终于是HTTPS了），并定期从服务器获取该用户的手势密码（换句话说，手势密码跨设备同步）。而获取手势密码的接口需要传入用户UID和ticket（在登录接口凭用户名和密码获取，是临时密码，相当于cookie）。
这看起来也很安全。然而，我注意到，服务器压根没校验ticket。用户UID随便一个接口都会返回，我可以在网页端打开其他同学的个人主页，在网页源代码找到用户UID。然后将用户UID传入接口，即可获取任意用户的锁屏手势密码。好在修改接口还会校验ticket，也获取不到登录密码。
嗯，这么低级的错误都能犯。我不知道该说什么。
3、拼接命令没有校验参数合法性
该系统的平板由另一供应商提供，平板中预装了一个用于控制权限的应用（以下称为mdm_permission）。mdm_permission没有主动动作，但是当其它应用（多为智慧课堂平台预装的应用）调用它时，平板供应商预装的应用便可根据指令授予或禁用第三方应用的权限。
就不说mdm_permission有没有鉴权了，它还是通过调用appops授予/禁用权限的。于是mdm_permission便只根据包名和权限名拼接命令，丝毫不管包名或权限会不会是 ; echo hello ; 这种可能。
然后，mdm_permission还是具有system权限的系统应用。
好消息是，mdm_permission有亿点点难调用。一般的第三方应用看不见的。
4、设备解锁存在的安全问题
回到锁屏的问题。
我们注意到，智慧课堂设备的主要应用是教室，这是人员密集的地方。在这里输入锁屏密码，极易被有心之人看到。
因此，我认为，在此种情况下，最好的解决方案，应该是生物识别。如，指纹识别。
不过，就不知道以利益为重的厂商愿不愿意花钱买识别传感器了。
解决问题的建议
第一，引入HTTPS保护。哪怕只是Let’s Encrypted证书。不能让关键数据在网络上裸奔。
第二，鉴权。做好Code Review，该鉴权时必须鉴权。
第三，不要小看客户，并不是初中生都不会编程。
