Web安全&软件安全

• sql注入
  • 代码直接用参数拼接sql，导致和union、=等恶意sql拼接成为非法sql，导致返回敏感数据或者返回成功
  • 措施
    • 参数进行base64编码
    • 参数化查询
    • 使用存储过程
• stack overflow
  • C、C++中，可以通过指针、scanf等内存操作直接操作内存，因此如果不做参数检查，就有可能导致输入的数据越界，如果估计拼接后续参数内容为系统命令并修改了函数返回指针到他的代码/命令段等，就可能执行这些命令或程序，如和黑客的服务器建立ssh连接，进行进一步的破坏。
  • Java、C#等语言不会有这种问题，如果因为引用其他库导致了内存越界，会直接报异常。
• XSS攻击
  • 用户参数数据传入js脚本，存到数据库中，下次取到页面上时有可能就直接执行脚本了
  • 对于CMS等系统中的富文本编辑器比较麻烦，不确定哪些是合法的，哪些是不合法的
  • 措施
    • 入参进行html编码
    • 用csp可以阻挡一部分负面效果，如访问其他站点
• 不要用整型做true、false的判断，有时自己都会搞乱，C、C++中会把0以外的都成true，如果你不小心返回了-1，后面的判断中就有可能把它也当成true了。。。
• 登录等密码相关的接口，要限制访问频率，避免暴力破解
• 用户退出登录再重新登录时，如果cookie中有旧的session id，那么不能延用，最好重新生成一个guid或者带时间随机数的
  • 这样的话，黑客即使拿到session id，最多也就在过期之前用一用，不然的话，用户下次又登录而session id不变的话，会导致黑客又能干坏事了。
• 禁用没必要的端口
• 打程序包时不要把没用的甚至敏感的文件也打进去
• 打程序时要出release版本，debug版本会有函数名等调试信息，代码混淆也没有用，反编译后会太容易看了。
• 使用新的程序包时要做检验看是不是合法的包
  • 措施
    • 出build打包时用公司私钥签名，然后在用新包升级时用公钥做检验
    • 代码中用定制的hash等算法，然后每次上传更新包时要把用这个特定的算法算出来的hash值一起传上来，然后程序中再算一遍，做对比
      • 其实也不是很安全，因为反编译可以猜出算法及其使用的key，只不过这个key和算法不好找
      • 如果是嵌入式系统使用SQLite等嵌入的数据库，那么数据库的密码最好不要明文放到代码或者配置文件中，会被反编译出来。可以考虑前面类似的方法。当然也只是提高了难度，黑客要去找和理解算法、key。