认知 行动 坚持

大家好。今天，我们来聊编程中很重要的安全问题，即CSRF，英语全称是：Cross-Site Request Forgery(跨站请求伪造)。产品的安全性，是第一位的，也是很多公司的红线要求。离开安全性，便一无是处。在这里，顺便友情提醒大家： 遇到不明链接，不要随意乱点。 在登录银行网站后，要记得退出登录，而不是直接关闭网页。 A的正常转账操作A登录银行账户后，给B转账100元，银行后台会校验登录态skey, 最后转账成功，http请求如下(本文全部用http来描述)：

注册和登录，是互联网产品的最基本功能，这里涉及到很多安全问题和用户便捷问题。今天，我们来简要聊一下手机验证码登录。 在之前的文章中，我们聊了注册登录原理及密码安全问题，这种方式是基于账号密码登录的。 然而，这种方式中，用户注册时需要填写很多繁琐信息，用户还要记住各种系统的账号和密码，烦人得很。 于是，很多网站都开始支持第三方登录，比如使用微信登录或QQ登录，即使用第三方账号体系登录，具体的原理...

大家每天都在用https, 今天，我们来聊聊它的原理。 我们知道，http基于TCP协议，明文传输，不安全。https是加密传输，安全。任何不使用https的网站都是流氓网站。https的本质是加密传输，它需要解决一系列的秘钥管理问题。 https很简单，关键在于理解其背后的思路，这些思路可以指导我们设计更加安全的系统。另外，https也是笔试和面试的常考点。

QQ音乐、王者荣耀使用微信和QQ登录，是不是第三方登录？ 是的，但毕竟它们都是腾讯的亲儿子，所以能获取更多的权限和接口。微信和QQ账号，已经成为用户在网络上的身份ID.腾讯手握微信和QQ两大账号体系，所向披靡。我们可以看到，通过SSO, 如果用户登录了淘宝，自然就登录了天猫。如果退出登录淘宝，天猫自动退出登录。SSO的原理并不难，搞懂了SSO, 有利于理解前端和后台的一些重要知识。SSO也是很多笔试和面试的常见考点。

在前面的文章中，我们讲了持久型XSS和反射型XSS, 我个人觉得这些命名真的很贴切，反应了概念的本质。 无论是持久型XSS还是反射型XSS, 恶意的js脚本内容都需要由服务端返回给用户，今天我们要说的Dom型XSS却例外，一起来看看。

在前面的文章中，讲述了最好懂的存储型XSS攻击和防御，本文来聊聊反射型XSS，所谓反射，就像镜子一样，一束光发过去，立即弹回来。这里依赖于微博服务器存在反射XSS漏洞。那么，坏人C为什么不自己搭建一个反射服务器进行反射呢？ 这是个好问题。以js获取cookie为例，如果坏人C自己搭建反射服务器，那么很显然document.cookie就无法获取好人A的微博cookie，所以，还是要用微博服务器做反射，这样才能获取好人A的微博cookie，从而进行攻击。

XSS原名CSS(cross-site script), 但与CSS(cascading style sheet)重名，所以就改名为XSS, 今天我们来了解一下XSS攻击和防御。 XSS的本质是：坏人C写了一个恶意js脚本，然后让好人A的浏览器去执行这个恶意js脚本，从而实现对好人A的攻击。XSS有持久型、反射型和DOM型。持久型XSS是最好懂的，危害很大，本文会以持久型XSS为例，来说明XSS攻击和防御方法。

产品的安全性，是第一位的。在之前工作中，坏人曾使用CSRF(cross-site request forgery)进行过恶意攻击，今天来聊一下CSRF攻击及防御。顺便提醒大家： 1.遇到不明链接，不要随意乱点。 2. 在登录银行网站后，要记得退出登录，而不是直接关闭网页。

一个网站或APP, 如果没有用户，那就没有价值。所以，如何吸引用户注册和登录，是一个重要问题，这就涉及到账号体系了。 自建账号体系的注册和登录，前面文章已经讲过。可是，很多用户并不想注册你开发的网站或APP，此时可考虑用第三方账号登录，比如微信登录和QQ登录。从目前现状来看，微信用户数早已突破10亿，以微信作为第三方登录越来越普遍，微信开放平台对企业合作伙伴进行赋能，彼此互为依存，利益共享。

安全性，是一个公司生死存亡的关键，华为、腾讯和阿里等公司，都有大量的技术人员来保障业务安全。平时工作中，一旦遇到安全问题，必须立即高优先级处理。安全攻防，是一个动态的博弈，没有攻不破的防守，也没有防不住的进攻。

最近， 碰到这样一个实际问题， 对同一个串采用同一个加密算法， 每次的结果都不一样， 但解密后， 又都能正确还原， 挺有意思的。       这是个封装了的加密算法， 我没有直接去看内部实现的源码， 但如上特性是很好实现的， 我也想到了实现方法。       有兴趣的朋友可以想一下， 怎么实现如上特性。

最近需要通过https访问某接口， 我用浏览器访问， 返回的结果准确无误。 但是， 用linux curl命令来访问， 居然就有问题了， https://xxx网站返回得信息是参数缺失， 我勒个去， 于是， 用libcurl重新写了一个https的访问程序， 一切work OK了。 这个问题， 折腾了很久。 备注： 一个星期后， 我知道这个原因了， 原来， curl "https://xxxx"才是正规用法， 需要加上引号。        之前遇到这样一个问题： 浏览器访问https

我对互联网安全很有兴趣， 买了这本书， 看完了， 更像是科普书。       写得不咋地。

转载地址：https://www.cnblogs.com/jhj117/p/5945866.htmlHash是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。如果两个散列值是不相同的（根据同一函数），那么这两个散列值的原始输入也是不相同的。这个特性是散列函数具有确定性的结果，具有这

来看看表的结构：mysql> show create table zzz;+-------+------------------------------------------------------------------------------------------------------------------------------------------------...

        转载地址：https://www.byvoid.com/zhs/blog/string-hash-compare        常用的字符串Hash函数还有ELFHash，APHash等等，都是十分简单有效的方法。这些函数使用位运算使得每一个字符都对最后的函数值产生影响。另外还有以MD5和SHA1为代表的杂凑函数，这些函数几乎不可能找到碰撞。　　常用字符串哈希函数有BK...

       本周二， 去外面吃了个饭， 扫码点餐，微信支付， 成功付款26元， 但页面提示失败， 且提示让我稍等， 不要尝试继续支付。 等了一会儿，没有结果。 店里人很多， 没来得问是什么情况， 就再次支付了， 第二次成功。当我查看微信支付记录的时候， 发现扣款两次了。 1分钟后， 另外一个吃饭的人， 也反馈了这个问题， 我们找老板反馈， 老板同意退钱， 甚好。 其实， 这种重复扣款的问题， 是...

       准确地说， 这个标题是有问题的， go gin只能给浏览器返回操作cookie的指令， 真正执行cookie操作的是浏览器。 但广泛地来讲， 说go gin操作cookie， 也是可以的（间接操作）       来看go gin代码：package mainimport ( "github.com/gin-gonic/gin")func main() {...

       转载地址：https://yq.aliyun.com/ziliao/317883             如题，本文主要介绍两方面内容：首先简单介绍浏览器的同源策略与其带来的问题；其次，介绍Cookie的作用域，即Cookie与Domain(域名)的上传关系，即浏览器在什么时候提交什么Cookie到服务器，即浏览器是通过怎样的规则筛选Cookie并提交到服务器的。一、 ...

在传统思维中， md5是单向变换， 很难破解。 当然， 这仅仅是理论。 在实际中， 人们可以提前构造一张从原串到md5的映射表， 一张非常庞大的表。 这样， 就可以破解一些常见的原串了。 这就是彩虹表的思想。       我亲自试了一下， 对于很多简单原串的md5,  网上很多工具是可以秒破的。 如果原串比较复杂， 则不容易破解。 所以， 大家设置密码的时候， 还是尽量复杂吧。

间接转载地址： http://blog.youkuaiyun.com/daliaojie/article/details/42171177一，背景：用户数据泄露一直是如今互联网世界的一个焦点，从最近的京东撞库抹黑事件，到之前的优快云，如家用户数据的泄露，服务商和黑客之间在用户数据这个舞台上一直在进行着旷日持久的攻防战。对于大多数用户而言，撞库可能是一个很专业的名词，但是理

转载地址：雷锋网 https://www.leiphone.com/news/201607/zrkxVMwYp93w39qD.html本文作者：史中2016-07-11 11:41专题：100个顶级黑客的故事导语：他用数学公式描绘了赛博世界的秘密，在浩瀚的可能性中，打开那扇飞驰而过的漏洞之门。

今天， 我们来说说https,  也就是安全的http.        怎么个安全法？ 那肯定是要对传输的数据进行加密， 为了效率， 我么可以考虑用对称加密算法， 如典型的AES.  那么问题来了， 客户端和服务端怎样才能拥有相同的对称秘钥key呢？  显然， 可以考虑从客户端端随机生成一个秘钥， 然后传递了服务端， 这不就行了吗？ 是的。        但是， 传递这个秘钥的过程， 是一

转载地址： https://segmentfault.com/p/1210000009605128/read          看完你就知道什么是 HTTPS 了阅读 2528，5月31日 发布，来源：juejin.im什么是 HTTPS ?不管是使用手机还是电脑上网，都离不开数据的通讯现在互联网上传输数据，普遍使用的是超文本传输协议，即

在早几年， 很多网站都用明文来存用户的密码， 结果被拖库了， 裤子脱了， 用户密码被泄漏， 然后就洗库、撞库， 黑产富得流油。 呵呵哒。         后来， 开发人员学学乖了， 传输和存储都不用密码的额明文， 而采用md5值， 这样似乎就解决了问题。 网站后台也不知道用户的密码。         可是， 有一种表， 叫彩虹表， 能根据md5的值反解密码， 于是， 开发人员又学乖了， 采

在多数人看来， https是安全的， 因为https和secure http嘛， 真的是这样吗？        一些人认为， https是加密传输， 所以抓到包也没有用， 是密文的。 真是的这样吗？ 我今天无意抓到了某网站登录的密码， 是明文的， 有点吃惊， 结果上网查了一下， 发现还是有不少网站在用https传明文密码。        下面， 我们以知乎的登录过程来看看，输入密

原文地址：http://www.youdzone.com/signature.html        翻译地址（阮一峰）：http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html        超赞

1979年，那是一个春天，有一位老人在中国的南海边画了一个圈，神话般地崛起座座城，奇迹般地聚起座座金山。      1996年， 又是一个春天， 有一位hacker写了一个程序， 可以高速发出tcp syn包， 并且这个syn包的源ip地址被强制随机造假， 于是乎， 服务端接收到syn后， 迅速为每个syn包分配一个incomplete队列， 其中的socket都是暂时没有完成连接的syn_r

最近遇到一个问题， 服务器遭受了CSRF攻击,  我们在之前的博文中也介绍了CSRF攻击和防御， 故不再赘述。       修改方法是， 服务器增加CSRF配置， 对token进行校验， 这样就能阻挡坏人的访问了！  阻挡后， 当坏人访问时， 返回403,  无情地拒绝坏人的方法， 气死他

#include // KEY 非常重要，不能对公众泄露KEY值// 发送端和接收端提前秘密约定好KEY值#define KEY 1313113 // 万岁万岁万万岁using namespace std;// 加密算法可以公开int encrypt(int plainText, int key){ return plainText ^ key;}

有空了，再写！

我们知道， 靠谱的账号注册登录系统， 是不能直接存放用户密码的， 也不能加密存放， 而应该通过哈希来存放。 当然， 也不能直接哈希， 否则脱裤后会被彩虹表所破。 那么， 就应该加点盐， 但是， 我看到网上有介绍说， 用这种方式来加盐存储：md5(md5(passWord) + userID)       我晕， 用userID做盐值， 很危险啊。 一旦脱裤， 用二重彩虹表， 也是很容易破解某u

在西游记中， 美猴王经常去天宫请救兵， 那么天上的玉皇大帝怎么判定这是真美猴王还是假美猴王呢？       可以考虑这样一个机制： 第一次确认是真美猴王后， 玉皇大帝给真美猴王颁发一块腰牌， 也即令牌（token）.   以后就不怕无法区分真假美猴王了， 哪个美猴王有这个token, 就认为是真， 否则是假。       你想想， 如果这个token丢失、泄露或者盗用， 那就糟糕了， 呵呵

登录态，票据和token是个什么玩意儿？ 我们慢慢来说。       以微博为例， 当用户在微博app中输入账号和密码登录后， 微博后台会进行验证， 看看账号和密码是否匹配， 如果匹配， 就登录成功。 用户后续在微博中发帖的时候， 就不需要再输入密码了， 只需要输入内容即可。 这里有个问题， 如果是坏人用别人的账号伪造发帖请求呢？ 岂不是代替比人发帖了？ 荒唐得很啊。       微博后台

转载地址： https://blog.coderzh.com/2016/01/10/a-password-security-design-example       在前一篇文章《设计安全的账号系统的正确姿势》中，主要提出了一些设计的方法和思路，并没有给出一个更加具体的，可以实施的安全加密方案。经过我仔细的思考并了解了目前一些方案后，我设计了一个自认为还比较安全的安全加密方案。

转载地址：https://blog.coderzh.com/2016/01/03/security-design/               引子最近有个虚拟练习项目，涉及到系统安全保障的设计，于是对安全保障这块做了一些更深入的了解。发现了很多有趣的东西，开阔了眼界。中间查了一些资料，于是我打算重新整理，用更加循序渐进，大家都能懂的方式，说一说如何设计一个

转载地址： https://libuchao.com/2013/07/05/password-salt为什么要在密码里加点“盐”盐（Salt）在密码学中，是指通过在密码任意固定位置插入特定的字符串，让散列后的结果和使用原始密码的散列结果不相符，这种过程称之为“加盐”。以上这句话是维基百科上对于 Salt 的定义，但是仅凭这句话还是很难理解什么

转自：阮一峰的网络日志（一、二）       强力推荐http://www.ruanyifeng.com/blog/2013/06/rsa_algorithm_part_one.htmlhttp://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html      我来总结一下：甲方要向乙方发送信息时，RSA加密如下：

今天， 我们来考虑这样一个问题： 你写了一个软件tool.exe,  别人想买， 需要花1块钱， 然后你把tool.exe发给他， 他就是你的用户了。 问题是： 你怎么防止tool.exe被无限复制和传播呢？ 这样岂不是就挣不到钱呢？       这就涉及到软件许可证的控制了。 你看， 我们平常用的一些软件， 经常需要搞个验证码什么， 就是类似的道理。       这里， 我们考虑

最近， 出了一个安全问题， 某号的登录态被盗用， 导致发布恶意诈骗内容， 要定位处理。        一旦出了这种安全问题， 各方就容易起鸡皮疙瘩， 安全同学一顿猛催， 其他方也是一样。 在毫无根据的情况下， 一些人猜测是原因a, 猜测是原因b, 有说是原因c, 总之， 要表现得非常在乎， 让其他人做一些漫无目的的验证。        我一开始就陷入了这个思维， 要查为什么， 要查出为什么