笑看尘世|网络安全逐渐成为程序员的必备技能

我是一个着迷于产品和运营的技术人 , 乐于跨界的终身学习者 。 欢迎关注我哟~
每周五早6点 按时送达~
我的第「158」篇原创敬上
大家好 , 我是Z哥 。
不知道大家有没有发现 。 如今 , 曝光某些知名公司信息泄露的事件频率越来越高 。 与之对应的 , 网络安全问题也越来越受到重视 。
从百度指数摘录了两张图给大家分享下 。
笑看尘世|网络安全逐渐成为程序员的必备技能可以看到 , 对网络安全相关的信息和关注度在逐渐走高 , 特别是近几年的几次大型数据泄露等安全事件引起了不小的舆论轰动 。
说实话 , 现在在企业做CTO风险还是蛮大的 , 万一所在的企业出现什么网络安全事件 , CTO也得承担责任 。
虽然说我们广大程序员们不用承担责任 , 但是一旦经你手发生的安全事件 , 你自然也会受到或多或少的牵连 。
写这篇文章的时候正好想起一个段子 , 分享给大家图个乐:
有人问一位搞 WEB 安全的人为什么 PHP 是世界上最好的语言 , 他的回答是 PHP 网站漏洞多 , 有饭吃 。
这可能也是目前PHP的声音越来越小的原因之一吧 。
其实排除一些特定框架中的特定安全问题 , 具有普遍性的安全问题也不少 。 其中最常见的就属以下几种 , 我觉得我们每一位程序员应该都要知道如何尽量避免这些常见问题的发生 。

  1. SQL注入
  2. 跨站脚本攻击(XSS)
  3. 跨站请求伪造(CSRF)
  4. 越权漏洞
/01 SQL注入/SQL注入应该是最多人知道的一个安全问题 。 原因是由于SQL语句的编写是通过字符串拼接进行的 , 包括参数 。 那么一旦用户输入的参数改变了整个语句的含义 , 执行SQL语句的结果就变得不可预期了 。 比如 ,
SELECT * FROM user WHERE id = ‘1 or 1 = ‘1’。 加粗部分就是用户输入的内容 。
如果上面的这段SQL语句被执行 , 用户信息就全部泄露了 。
SQL注入还有很多变种 , 比如故意让语句执行报错之类 , 从错误信息中获取重要信息 。
如何防范呢?只要避免SQL拼接 , 使用参数化的方式执行SQL即可 。 比如上面这个例子 , 如果@id参数的数据类型是int , 那么「or 1=‘1」自然无法转换成int类型 。
/02 跨站脚本攻击(XSS)/XSS最常出现在一些内容型站点上 , 因为他主要针对的是根据服务端数据动态渲染html的页面 。
【笑看尘世|网络安全逐渐成为程序员的必备技能】比如 , 当我在某个社区回复帖子的时候 , 故意输入了「楼主牛逼~」 。 如果服务端没有做好相应的处理 , 直接把内容原封不动的存到了数据库 , 那么当帖子翻到我的回复所在的楼层 , 就会在显示“楼主牛逼”字样的同时出现一个提示“250”的弹窗 。
当然 , 只是弹个窗没啥意思 。 如果脚本中获取用户本地的cookie信息上传到指定服务器 , 那么其他人就可以利用该用户的cookie登陆他的账号了 , 想想就有点后怕 。
如何防范呢?要么就是过滤掉这种html标签 , 因为大多数场景纯文本就能满足 。 如果实在有富文本的需求 , 可以进行一次转义 , 作为字符来存储 , 避免将html标签直接保存下来 。
另外 , 针对cookie可以设置一下httponly , 这样的话js就无法获取cookie信息了 。
/03 跨站请求伪造(CSRF)/CSRF就是利用浏览器的缓存以及网站的登陆状态记忆功能 , 通过恶意脚本向你刚访问过的网站发起请求 , 让网站误认为是你本人在操作 。
比如 , 你刚访问过某银行网站 , 甚至正在另一个标签页里打开着这个银行网站 。 然后此时不小心点又开了一个钓鱼网站 , 页面里面的脚本发起向该银行网站的转帐请求 , 你的银行账户就莫名其妙少了一笔钱 。 (当然现在的银行网站都考虑了这个问题)


推荐阅读