kimbs.cnkimbs.cn

安全问题的本质是信任的问题。

安全是一个持续的过程。

一、安全世界观

三要素：机密性，完整性，可用性 额外要素：可审计性，不可抵赖性
安全评估过程：资产等级划分，威胁分析，风险分析，设计安全方案。
互联网安全问题的核心，是数据安全问题。
优秀的安全方案： 有效的解决问题 用户体验好 高性能 低耦合 易于扩展升级
Secure by default 原则，最小权限，多用白名单。 白名单： 端口 软件 XSS允许标签 Flash crossdomain 允许跨域调用列表 Linux 普通用户+Sudo
纵深防御原则，从前端入口开始，层层加固。
数据和代码分离原则，对用户数据进行 过滤、编码 等手段。
不可预测性原则，让攻击者找不到规律，猜不到遍历规则，提高攻击门槛。 比如，CSRF 防御中使用的 token

二、浏览器安全

Web 构筑在同源策略之上。带 src 属性的标签加载资源，实际上是模拟 GET，加载资源，且被浏览器限制读写权限。Google chrome 采用多进程架构，进程间使用 SandBox 严格隔离。既提高了安全性，又使得体验提升。通过沙箱和api 对数据进行访问保护。比如 php 通过 api 调用本地文件，而不是直接访问。Google 的 SafeBrowing API 提供恶意网址库。先进浏览器支持 EVSSL 证书，即通常的绿色提示。比较有效地防钓鱼网站。X-Content-Security-Policy 及其灵活，功能完备，但是也增加了维护成本。

三、XSS

反射型，通过诱使用户点击含有攻击脚本的链接。
存储型，通过输入通道，把代码存储在服务器端。
Dom based 型，通过（利用）修改页面 Dom 节点形成 XSS
XSS Payload：用以完成各种具体功能的恶意脚本。脚本中包含大量 JS 代码，然后通过加载远程脚本，把数据发送到远端。
通过创建隐藏 img，把 Cookie 通过 src 传递到远程，获取到用户登录凭证。
Cookie 的 HttpOnly 可以在一定程度上防止被脚本劫持。让 IP 与 Cookie 绑定，也能起到防御作用。
通过模拟 Get 或者 Post 操作用户的浏览器，在隔离环境，或用户访问不了互联网的时候，起到攻击效果。
Payload 脚本可以通过 img 模拟 Get 加载，也可以创建动态 form 模拟 Post 请求。
通过 XMLHttpRequest 也可以模拟 Post 请求发包，操作客户端。
表单提交要求验证码，可以一定程度上防止一般的 Payload，但是攻击者可以发送验证码到远程进行破解。
修改密码时要求填写旧密码，这个一般攻击者是不知道的。
通过 JS 模拟登录框，骗取用户账号密码。
根据浏览器之间不同的独有对象，能准确判断浏览器的大版本。
通过判断控件 object ，可以判断用户是否有安装该插件。 通过 classid 列表，可以扫描所有可能安装的软件、扩展、插件。
通过 Java Applet 或者其它 ActiveX 控件接口，可以获取用户内网真实IP地址和网络信息。
code.google.com/p/attackapi/bindshell.net/tools/beef/
XSS Worm 利用一些未被屏蔽的标签，比如 style、background etc. 通过拆分法绕过敏感词过滤，能够复制自身攻击。
站内信、用户留言 等产生用户交互行为的页面，如果存在存储型 XSS ，则容易引发 XSS Worm
JavaScript 调试工具，Firebug、Fiddler、HttpWatch 等等
利用字符编码，可以绕过某些 XSS 过滤。 利用 event 事件，可以绕过某些变量长度限制。 可以通过 location.hash 隐藏 payload，也可以绕过长度限制。 可以通过注释，注释掉中间的代码，从而绕过长度限制。
base 标签非常危险，可以通过远程伪造图片、链接，劫持当前页面中所有使用 相对路径 的标签。
window.name 可以实现数据跨域传递，减少 payload 长度。
回旋镖 攻击，可以让反射型 XSS 变得更自动化。Flash 的 ActionScript 也可以用于 XSS 攻击，且非常强大。应该禁用 embed object 等标签。视频播放应该转成 flv 等静态文件。
—–
方案：
HttpOnly 解决的是 XSS 后的 Cookie 劫持问题。
输入检查，类似白名单，在前端和服务端同时做。不能用简单的 XSS Filter ，应该结合输入语境。
输出检查： 对所有 html 输出进行 htmlencode 对所有 javascript 输出进行 escapeJavascript + 双引号。 对所有 url 部分，使用 URLEncode 进行加密。 将除了字母、数字以外的所有字符，全部转换成十六进制的编码。 XMLEncode JSONEncode 禁止用户可以控制的变量，在 style标签、html标签的style属性、css文件 中输出。 对 href 要检查是否 http 开头，如果不是就添加。 要注意编码后，变量长度发生变化。
开发框架应该默认 escape 所有变量，达到 secure by default
富文本 应该禁止：事件，iframe，script，base，form 等等。 禁止：自定义 css 标签尽量使用白名单。
对 dom based xss ，要用多种过滤函数综合防御。

四、CSRF 跨站点请求伪造 Cross Site Request Forgery

通过 img 标签，模拟用户端 url 并执行，诱使用户自己点击 url 达到攻击目的。
禁止浏览器发送 Third-party Cookie 能够在一定程度上阻止 CSRF
服务器返回的 P3P 头，允许第三方引用跨域设置 cookie，将放行 第三方 Cookie 的发送。从而把 Cookie 的影响扩大到整个域的所有页面。
一般，在 a域 引用 b域 的页面，这个页面是无法设置 b域 的 cookie 的。 而当 b域 页面带上 P3P 头后，就可以跨域设置成功了。
P3P 头也可以直接引用 XML 策略文件。
构造一个恶意攻击页面，隐藏一个 iframe，iframe 地址指向 csrf 攻击页面。页面可以构造好 表单，并自动提交。
利用 串联 csrf 可以发起 worm 攻击。
——
防御手段
1、验证码，简洁有效。
2、Referer Check，防 csrf 的同时，还能防盗链。 但是有时候 Referer 头被限制发送。或者浏览器不发送 Referer 。
3、Anti CSRF Token，业界公认。最好使用 物理真随机 算法。每次输出页面，都输出 Token 放置在表单中，同时设置到对应 Session/Cookie 中。Token 同时存在于 表单 和 Session 中，服务器通过验证两者是否一致，判断是否合法。 其根据是 不可预测性原则。 Token 可以在会话周期内都有效，而不用每次都重新生成。直至表单成功提交，下次就刷新这个 Token。 可以通过同时多个 Token ，满足多个页面依次提交的需求。 Token 不要放到 url 上，防止通过 Referer 泄露。
XSS 可以读取页面中的 Token，从而发起 CSRF，这种攻击称为 XSRF

五、点击劫持 ClickJacking

通过透明层 iframe ，诱使用户点击功能性按钮。
Flash 也存在隐藏攻击。
图片覆盖攻击，Cross Site Image Overlaying，XSIO，利用图片的 Style ，覆盖原图片。防御方法是设置图片的 position 为 absolute。
要检查用户提交的 html 代码中，img 标签的 style 属性是否可能导致浮出。
拖拽劫持，诱使用户把隐藏内容，拖拽到另一个隐藏的 iframe 里面。
触屏劫持，TapJacking，利用隐藏层，遮盖手机屏幕。
——
防御方式：
禁止跨域 iframe，通过 js 禁止 iframe 嵌套，称为 frame busting，但是容易被绕过。
使用 X-Frame-Options 头，是目前最好的方案。

六、Html5 安全

H5 的 video 标签里面的属性有可能绕过 XSS Filter
Iframe 的 sandbox 属性极大地增强了应用的安全性。
a标签和其它链接标签的 noreferrer 属性，可以屏蔽 refer，保护敏感信息。
使用 canvas 甚至可以破解 验证码图片！
使用 Origin 和 Access-Control-Allow-Origin 头，可以做出精细跨域控制。可以防御 CSRF
wimdow 对象很容易被攻击脚本利用。
postMessage 可以实现跨窗口的消息传递，且不受同源策略限制，还可以跨越 sandbox。接收方绑定 message 事件，且要验证 url 和 domain，验证消息安全性。
Web Storage 可以保存同源下的数据，但是也留下了安全隐患。

七、注入攻击

注入的两个条件：用户可以控制输入，原本要执行的代码拼接了用户的输入。
应该禁止数据库错误回显。
盲注 Blind Injection，可以通过 and 1＝2 和 and 1＝1 ，共同确认参数是否存在 SQL注入漏洞。
Timing Attack，利用 BENCHMARK 函数，循环扫描判断出完整表名和其它有用信息。
sqlmap.py 是著名的自动化注入工具。
要禁止普通数据库用户具备操作文件的权限。 尽量避免给 Web 应用使用数据库的管理员权限。
用户自定义函数 UDF ，有可能被利用。
存储过程很容易被攻击，且本身也可能存在注入漏洞。
统一 数据库、操作系统、Web应用、前端显示页面 所使用的字符集，避免各层对字符的理解存在差异，比如 utf8mb4，是解决 基于字符集攻击 的好办法。
仅仅对输入进行 escape 往往是不够的，属于黑名单行为。
预编译语句是最好的防御手段。其次是使用安全的存储过程。
检查和限制数据类型，属于白名单方法，可以在很大程度上对抗 SQL 注入。
最小权限原则，禁止使用 admin、dbowner 等高权限账号直接连库。不同应用使用不同账号。Web应用的数据库账号不应该有 创建自定义函数，操作本地文件等权限。
XML 注入，防御手段也是把保留字符进行转义。
代码注入，多见于脚本语言，容易造成命令注入。要禁止 eval、system 等高等级函数，以及过滤用户的输入，避免动态 include 远程文件。防止 后门。
CRLF 分隔符注入，比如 注入 HTTP 头 攻击，假如服务器没有过滤 “\r\n” ，又把输入数据放在 http 头中。
HTTP Response Splitting 攻击，通过连续插入两次 换行符，强制结束 http 头，从而实现 xss 攻击。

八、文件上传漏洞

上传 Web 脚本 上传带有代码的文本，利用动态包含进行攻击 上传 crossdomain 等控制策略文件 上传病毒、木马 上传钓鱼图片、包含脚本的图片
大多数情况称为 webshell
尽量使用白名单，限制可上传的文件类型。
通过把 0x00 终止符插入到后缀之前，可以既绕过文件后缀检查，又能去掉正常后缀，使文件变成攻击脚本。
伪造 PHP 文件头，插入正常的图片头，可以利用某些特定情况下的漏洞。
不能单纯的依赖文件后缀来检查安全，要充分了解 web server 的文件解析过程。防止服务器解析漏洞。
IIS WebDav PUT MOVE 漏洞
利用网站的 302 跳转功能，可以构造钓鱼链接，比如 taobao.com/member/login.jhtml?redirecturl＝http://item.taobao.av.com/xxx
通过事先上传伪装成图片的脚本，可以隐藏上面 URL 中的钓鱼地址，使攻击更隐蔽。
防御手段： 1、文件上传的目录设置成不可执行 – find . -type f | xargs chmod -x 2、结合 MIME Type 、后缀检查 和 白名单 多种方式 3、使用图片压缩函数，使用 resize 函数，破坏其中的 html 代码。 4、使用随机数 改写文件名，和文件路径。 5、单独设置文件服务器的域名，比如 file.qf.56.com

九、认证和会话管理

密码强度，可以参考 OWASP 标准
密码加 salt 加密，可以使 Rainbow Table 攻击失效。
salt 应该保存在 机密配置文件 中。
多因素认证，比如 密码 加 数字证书 加 动态口令
Session劫持 和 Cookie劫持，常见的有 xss，网络sniff，本地木马窃取 等等。
设置 cookie 的 httponly 是必须。
不要把 sid 放到 URL 中，容易被 referer 泄露。 通过在邮件中添加图片，用户访问邮件，发起 get 请求，refer 被发送到图片所在的网站，用户 URL 中的数据就会被盗取。
也容易引发 Session Fixation 攻击。因此，在登录完成后，要重写 SessionID。
SessionID 要采用足够强的随机数生成算法。
Session 保持攻击，通过不停刷新 用户页面，保持 Session 不过期。或者通过不停发送 自定义 cookie 头的 http 请求。
不能信赖 cookie 的 expires 作为 SessionID 的过期时间，因为有可能被 xss 劫持并修改。应该由后端设定 expires 时间，到期后强制销毁 session
当用户 IP 或者 客户端 发生改变，则强制销毁 session。
尽量使用户仅可以同时间拥有单一 Session，即单设备登录限制。
单点登录 SSO，通常需要配合额外的认证机制，比如 进行支付时再次验证密码，或者进行手机短信验证。
OpenID 是最流行的单点第三方认证方式。比如 QQ第三方登录。

十、访问控制

基于页面的访问控制，能防止被 构造的 URL 字典搜索攻击。常见的方式是 URL Pattern 与 Role角色 对应列表。
Role-Based Access Control 基于角色的访问控制。用户 角色 权限。是 垂直权限管理 的一种。
基于表达式的访问控制，更加灵活。
基于 method 的访问控制，比如 Java 中的 @PreAuthorize 断言。
配置权限应该遵循 最小权限、默认拒绝、白名单 等原则，避免越权访问。
基于数据的访问控制，也叫水平权限管理。难以在一个统一框架下解决。 常用方法有 用户组Group ，同组内的成员才能实现数据操作。
OAuth RFC 5849，是从 OpenID 分离出来的，原本是想弥补 OpenID 在授权功能上的不足。
OAuth 2.0 针对请求数量庞大时进行了优化。

十一、加密算法与随机数

分组加密算法
流密码的加密，是基于异或 XOR 操作进行的。
Reused Key Attack，使用固定 key 作为加密秘钥的都有此风险！ E(A) xor E(B) ＝ A xor B 知道其中三个，就可以推导第四个，而不需要知道 key！
不要使用相同的 key 做任何事！
Bit-flipping Attack，应对方法是验证密文完整性，使用带 key 的 消息验证码（Message Authentication Code）。最常用的是 HMAC 算法。
HMAC 方法也常用于 接口参数加密检验。
不要使用流密码，比如 RC4 WEP 无线 wifi 加密算法 RC4，可以被暴力破解，不安全。
不管基于什么算法，只要用了 ECB 分组加密模式，改变分组密文的顺序，将改变解密后的明文顺序，且可以随意替换某个分组的密文，这样攻击者就有了机会。
不要使用 md5 和 sha1
Padding Oracle Attack，边信道攻击，类似彩虹攻击，暴力破解。可以在不知道秘钥的情况下，构造 IV 向量，解密出任意明文。 在实现 CBC 模式分组加密算法时，不要轻易泄露解密结果是否符合 padding 的信息。
Salts 和 IV 都要随机产生！
密钥不可以存放在代码中，被传播或者逆向破解都会导致危险。
56的做法，把密钥保存在 固定的服务器集群的配置文件里面，控制访问权限和维护人员，并且定期更新。且隔离生产环境和测试环境。
更安全的方式是通过 Web Service 提供获取密钥的 api
弱伪随机数问题。比如 以顺序增长的系统时间作为因子，特别是不要把时间函数当作随机数使用，容易被遍历破解。
mt_srand 播种 seed 也是有缺陷的，种子 有可能被猜到，然后通过程序还原出对应的伪随机数的值。
如果服务端接受长连接，通过发送 Keep-Alive 头，可以迫使同一进程响应请求，使得随机数只会在一开始播种一次。
Linux 中，/dev/random 或者 /dev/urandom 都是很好的随机数生成器
使用多个随机数及其加密的组合，可以增加攻击难度。
不要依赖系统的保密性！
推荐使用 CBC 模式的 AES256 用于加密。 推荐使用 HMAC-SHA512 用于完整性检查 推荐使用 带 salts 的 SHA256 或者 SHA512 用于 hashing

十二、Web 框架安全

PHP 在 view 层加入 magic quotes gpc ，但是没有在 model 层面解决注入问题，不推荐使用。
可以在 mvc 框架中集中修复漏洞，效率高。
View 层及模板引擎，针对不同上下文的 xss 攻击场景，使用不同的编码方式。
框架可以要求所有 写操作 都强制使用 HTTP POST，也可以在所有涉及 POST 的代码中添加 Security token 输出，及其验证。
302 跳转地址，以及 Location 字段，应该被白名单管理控制。
框架可以输出和管理 X-FRAME-OPTIONS ，而不一定完全依赖 Web服务器 去输出。
框架可以统一对所有 Cookie 默认设置 HttpOnly
框架可以使用 ORM 等框架，统一防御 SQL 注入。
框架可以实现统一的文件上传功能。
受到 xss 攻击时，应该记下 攻击者IP、时间、UserAgent、目标URL、用户名 等信息。后期 应该建立攻击事件分析、入侵分析。
Struts2 的作者对安全的理解差，代码漏洞多。

十三、应用层拒绝服务攻击

DDOS – Distribited Denial of Service
SYNC Flood，利用 tcp 协议中的设计缺陷，要修复几乎是不可能的了。 防御方式：Sync Cookie、Sync Proxy、SafeReset，减少 Syn Time 和 重试时间
肉鸡被攻击过程：发现漏洞，取得用户权，取得控制权，植入木马，清除痕迹，留后门，做好攻击准备。
应用层 DDoS 攻击 基于真实IP，比网络层 DDoS 更可怕。
CC 攻击，Challenge Collapasar，前身是 fatboy 程序。对一些消耗资源较大的应用页面发起大量正常请求。 属于应用层的 DDoS 攻击。
在大流量网站插入想要攻击的网址，就能变相发起 CC攻击。
代理猎手 等工具，可以使攻击IP 频繁变化。
防御：
在应用层面，在业务逻辑之前，针对每个 客户端 做请求频率限制。
应用代码要做好性能优化，增加缓存，及时释放资源，及时关闭数据库连接，减少空连接消耗。
架构上做好优化，负载均衡，利用好 cdn 和镜像站点分流。
Captcha 验证码，可以有效阻止自动化的重放行为。验证码文件名需要随机化，满足不可预测性。
让客户端解析到一段 JavaScript，可以判断客户端是不是浏览器。
在 Web Server 层做一些防御，调小 Timeout、KeepaliveTimeout ，增加 max clients 值。
根据 IP地址 和 Cookie 信息，动态计算客户端的请求频率，并进行拦截。
资源耗尽攻击，本质是 对有限资源的无限滥用。
SlowIoris 攻击，发送一个不完整的 http headers，比如只有一个 回车换行 的请求头，然后使用任意 http 保持连接。
Http Post DOS，指定一个非常大的 Content-Length ，然后以很低的速率发送字节，保持连接不断开。
Web应用防火墙，或者 定制的 Web Server 安全模块。
内存泄露 也可能导致被 DDoS 攻击。
Server Limit DOS ，通过向客户端写入超大 cookie，使得 Web server 拒绝服务。 Web服务器 应该在返回 4xx 的同时，置空该用户 cookie 或 session
ReDOS 利用正则解析引擎，输入需要大量资源解析的正则，造成 DDoS。 应用系统应该谨慎使用正则！

十四、PHP 安全

本地文件包含：
比如 ../../etc/passwd\0
要过滤变量中的 \0 字节
型如 ././././././ 可以构造长目录名
目录遍历漏洞 攻击，型如 ../../../../../../../../ ，还可以通过不同编码绕过服务端检查。
要限制程序能够打开的文件/目录，比如 PHP 中的 open_basedir
尽量避免包含动态变量！尤其是用户可以控制的变量！如果一定要包含，则应该使用白名单。
远程文件包含：
Remote File Inclusion，RFI，可以用 ？号截断代码中的文件 base path，转而执行攻击者设置的远程文件。
危险： 包含用户上传的文件(高危) 包含 data:// 或 php://input 等伪协议 包含 session 文件 包含日志文件，比如 Web Server 的 access log 包含 /proc/self/environ 文件 包含上传的临时文件（RFC1867） 包含其它应用创建的文件，比如数据库文件、缓存文件、应用日志等
必须关闭 allow_url_include 必须关闭 错误回显，防止暴露目录 必须禁止 system 等系统函数 必须指定上传文件的临时文件目录 upload_tmp_dir 必须关闭 register_globals，并禁止用户在 url 中初始化变量 最好禁止 extract、import_request_variables、parse_str 等函数，防止变量被覆盖
尽量限制全局变量，因为攻击者有可能通过覆盖变量，引入 XSS、SQL 等攻击，或者代码执行
检查代码，确保变量被初始化！
针对 远程代码执行漏洞。首先要谨慎使用，必要时禁用 eval system popen passthru assert exec shell_exec escapeshellcmd pcntl_exec 等等敏感函数。
针对 文件写入执行代码。要防止用户在文件写入前改变文件内容。
高度重视 include, include_once, require, require_once
重点关注 file_put_content, fwrite, fputs 等文件写入函数
小心 preg_replace 的 /e 修饰符
禁用动态函数执行，禁用 create_function
Curly Syntax 花括号也能执行代码，型如 ${ls}
注意回调函数，可以执行 callback 参数的函数，执行的地方也经常被利用
ob_start 也可以执行回调函数！
unserialize 和 __destruct 和 __wakeup 组合，也可以注入代码执行
php.ini 的安全配置： register_globals=Off open_basedir=xxx/xxx/ allow_url_include=Off display_errors=Off log_errors=On magic_quotes_gpc=Off cgi.fix_pathinfo=0 session.cookie_httponly=1 session.cookie_secure=1
独立的应用环境，推荐使用 disable_functions 来禁用危险函数
共享环境，需要禁用更多函数。

十五、Web Server 配置安全

为 Web Server 设置独立的 user/group ，且不具备 shell 权限，切忌使用 admin 或者 root
Nginx 设置 limit_except，判断 http_referer 是否空，判断 request_method 是否是 post，判断 query_string 是否是 login ，从而判断是否 ban 掉该请求
jBoss、Tomcat 等服务器都曾出现过 war 包上传等漏洞
Http Parameter Pollution，HPP 攻击，利用软件对参数的混淆，绕过 SQL注入检查

十六、互联网业务安全

安全，是产品的一个特性。
最理想的产品安全，是潜移默化地培养用户的安全习惯，将用户往更安全的行为上引导。
挂马网站，是被黑客入侵，篡改了网站页面，植入攻击代码，利用页面高访问量，攻击网站用户。
优秀的安全方案包括：良好的用户体验，优秀的性能。
复杂密码也是一种糟糕的体验。
用户注册时，可以立刻就收集到用户的一些个人信息，比如 用户名、邮件地址、生日、电话号码 之类，如果被用于密码，则可以立刻提醒用户。
业务逻辑安全问题，比如 保存多份账号密码，都是很大的安全隐患。
一般来说，应该隐藏用户的账号 ID
修改密码，一定要求用户输入当前密码，甚至使用双重验证。
密码取回流程，如果 安全问题验证、安全邮箱、预留手机号码，这些都失效的时候，可以使用用户在网站上留下过的私人信息，与用户逐一核对。比如曾经使用过的密码、曾经登陆过的地点、曾经发表过的言论过文章内容。
账号被盗的途径，及其评分： 没有使用 Https，密码被网络嗅探 – 13 客户端中了木马，被键盘记录嗅探 – 8 用户被钓鱼网站迷惑 – 12 网站某登录入口可以被暴力破解 – 15 网站 修改密码 或者 取回密码 流程存在逻辑漏洞 – 14 网站被 XSS ，账号被间接盗取 – 11 网站存在 SQL 注入漏洞，被黑客入侵 – 12
对抗 ARP 欺骗： 带 DAI 功能的思科交换机 静态绑定 IP 地址和 MAC 地址
黑客也有自己的群体，可以打入这些群体，获取有用的资料。
目的不是为了网站所提供的服务的注册账号，都属于垃圾账户。
任何可以留言，以及产生用户交互的地方，都可能会被垃圾消息盯上。
垃圾账号的特点是 批量 和 自动化。
如何识别批量和自动化： 同一客户端多次请求同样的 URL。 页面和页面之间的跳转流程不自然，不像正常用户行为。 同一客户端两次请求之间的时间间隔短。 有时客户端的 UserAgent 看起来不像浏览器。 客户端可能无法解析 JavaScript 或 Flash。 在大多数情况下验证码有效。
垃圾内容识别： 注册时填写的用户名可能是随机生成的字符串，而非自然语言。 不同账号的资料介绍可能出现同样的内容，特别是广告账号。 含有政治或商业敏感词。 出现文字的变形，比如半角变全角。
IM 识别： 某用户给很多用户发送消息，但是接受者都不回消息，那就可能在发垃圾消息。 某个用户加入不同的群，但是发送的消息总是同样的内容，不说其他话，则可能在发送垃圾消息。
垃圾行为特征分析： 基于内容的规则：以自然语言分析、关键词匹配等为代表。 基于行为的规则：以业务逻辑规则为代表。 基于客户端识别的规则：以人机识别为代表，比如验证码，或者客户端去解析 JavaScript
比较完善的风控系统： 在事中监控拦截高风险的用户行为。 在事后追溯恶意用户，取证、统计损失。 在未来给决策提供依据。
保护规则：对不是特别紧急的业务，可以打时间差，识别出垃圾账户后，过一段时间再处理。
邮件钓鱼，通过伪造 发送者，引诱用户访问钓鱼网站。
网站应该对自己的内容，特别是用户之间交互的内容，检查钓鱼网站漏洞。
Google 公布的 Safe Browsing API，提供了 钓鱼网址、挂马网址、诈骗网址 的黑名单。
国内主要通过 CNNIC 下属的反钓鱼联盟 APAC，对钓鱼网站进行强制关停。
钓鱼网站 骗取用户的支付密码、登录密码，还可以利用隐藏表单，引诱用户给其银行账户转账，骗取钱财。
网上支付流程的重大缺陷，来自于 贯穿不同平台的唯一标识，是订单号。而订单号只包含了商品信息，无法包含太多的用户相关信息。 这就给了攻击者可乘之机，骗子可以去商户创建一个订单，然后引诱用户去第三方支付平台支付。或者在第三方支付平台创建一个订单，然后交由用户去银行支付。
PCI 标准：不存在的数据是最安全的。
保护用户的隐私： 用户应该拥有知情权、选择权。 网站应该妥善保管收集到的用户数据，不得将数据用户任何指定范围以外的用途。 网站应该限制员工接触原始数据。 个人数据应该只能由算法或者程序来计算，工作人员不应该有直接查看的权限。 比如，手机号、身份证号 都可以用掩码的方式隐藏。

十七、安全开发流程

Security Development Lifecycle，SDL： 1. 培训 2. 安全要求沟通 3. 质量门，bug栏确认 4. 安全和隐私风险评估 5. 设计要求 6. 减小攻击面 7. 威胁建模 8. 使用指定的开发工具 9. 弃用不安全的函数 10. 静态分析（静态代码扫描） 11. 动态程序分析（QA） 12. 模糊测试 13. 威胁模型和攻击面评析 14. 事件响应计划 15. 最终安全评析 16. 发布/存档
敏捷 SDL： 1. 定期充分与项目经理沟通，安排足够时间。 2. 立项流程里面，确保安全团队介入，避免遗漏。 3. 为安全部门树立权威，项目必须由安全部门审核完成后才能发布。 4. 将安全技术方案写入开发和测试的工作手册中。 5. 给工程师培训安全方案 6. 记录所有的安全bug，定期 review，激励程序员编写安全的代码。
需求分析阶段，按照 安全规范CheckList 进行评估。（网上很多）
需要评估第三方软件的安全问题。
可以制作 安全函数列表，以及 安全内容输出 的写法模板，方便安全检查和扫描。
代码自动审计和人工审计结合。
测试阶段的安全测试，应该独立于代码审计而存在。主要是要测试出 逻辑漏洞 和 难以发现 的复杂问题。
可以使用 Web 安全扫描器进行扫描。比如 skipfish

十八、安全运营

安全是一个持续的过程。需要把 端口扫描、漏洞扫描、代码白盒扫描 等发现问题的方式变成一种周期性的任务。
Security Operation Center，SOC 把安全日志、安全事件关联起来。
漏洞修补流程 的建立很重要。比如把 bug 在 bugtracker 中提交并定义为 需要紧急修补 的等级。
补丁的代码也需要由安全员 review
对曾经出现的漏洞进行归档，并定期统计漏洞修补情况。
安全监控与报警，Defend and Defer
安全监控产品：IDS 入侵检测系统、IPS 入侵防御系统、DDoS 监控设备、WAF 应用层防火墙。比如 phpids，apache 的 modsecurity 模块。
报警方式： 邮件报警 IM 报警 短信报警
紧急响应小组： 技术负责人 产品负责人 最了解技术架构的资深开发工程师 资深网络工程师 资深系统运维工程师 资深 DBA 资深安全专家 监控工程师 公司公关
安全事件发生时： 保护安全事件现场。比如把被入侵的机器下线，隔离分析。 以最快的速度处理完问题。务必在最短的时间内找到对应的负责人，制定相应的计划，流程尽量缩短。