### 不参与验签规则
1. 如果key中包含WithoutSign,该key不参与验签;
2. 请求url的字符串，如果请求的url中包含WithoutSign,该接口不参与验签；
### 验签
#### 协议规则
1. 传输方式：为保证交易安全性，建议采用HTTPS传输
2. 提交方式：采用POST方式提交
3. 数据格式：提交数据都为json；返回数据采用JSON
4. 字符编码：统一采用UTF-8字符编码
5. 签名算法：MD5
6. 签名要求：请求和接收数据均需要校验签名，详细方法请参考安全规范-数字签名
#### 签名算法
1. 除sign字段外，所有参数按照字段名的ascii码从小到大排序后使用QueryString的格式（即secret=yh&key1=value1&key2=value2…）拼接而成，空值不传递，不参与签名组串。
2. 公式：sign=Md5(原字符串).toUpperCase
3. 举例说明：deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd
4. 得到的sign=Md5(secret=yh&deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd).toUpperCase()=7648CE21E5FF1C9B905B3344660CC12D
5. header中的值参与验签；
#### web端
1. web端的secret传yhWeb
#### app客户端
1. Header中需传以下参数：deviceId(手机唯一标识，ios使用udid)、producer（android使用android.os.Build.MANUFACTURER、ios使用固定字符串apple）、channelId（渠道id，ios使用app store）、ip(手机的ip地址)、timestamp(请求的当前时间戳)、platform(android、ios、web);
2. secret=yhAdnroid***** yhIos*****
#### java端
1. 对签名做验证；
2. yh:safe:cc:唯一标识-时间戳-方法名 作为key存到redis中，有效期是五分钟(存到配置文件)，值value第一次是1，第二次是2，第三次是3，如果超过3不响应该请求；
3. 拉黑机制：新增数据库 yh-safe :新增表 ecs_user_safe(中有字段 is_black),取过一次之后放到redis中，yh:safe:black:usernameList;
## 交互
### 攻击类型
1. sql注入；
2. 参数篡改；
3. xss攻击；
4. 防盗链；
5. 文件上传漏洞攻击；
6. cc攻击；
7. CSRF（Cross-site request forgery）跨站请求伪造；
8. ddos;
#### xss
1. 定义：XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的. 比如获取用户的Cookie，导航到恶意网站,携带木马等。
2. 防护：
* 使用HTTPS！就跟我前面《HTTP与HTTPS握手的那些事》这篇文章说的，HTTPS会在请求数据之前进行一次握手，使得客户端与服务端都有一个私钥，服务端用这个私钥加密，客户端用这个私钥解密，这样即使数据被人截取了，也是加密后的数据。
* 特殊符号过滤
## 盗链
1. 盗链是指服务提供商自己不提供服务的内容，通过技术手段绕过其它有利益的最终用户界面（如广告），直接在自己的网站上向最终用户提供其它服务提供商的服务内容，骗取最终用户的浏览和点击率。受益者不提供资源或提供很少的资源，而真正的服务提供商却得不到任何的收益。
#### cc攻击
1. 因为CC攻击来的IP都是真实的，分散的；
2. CC攻击的数据包都是正常的数据包；
3. CC攻击的请求，全都是有效的请求，无法拒绝的请求。
4. 攻击者借助代理服务器生成指向受害主机的合法请求，实现DDOS和伪装就叫：CC(ChallengeCollapsar)。
5. CC就是充分利用了这个特点，模拟多个用户（多少线程就是多少用户）不停的进行访问（访问那些需要大量数据操作，就是需要大量CPU时间的页面）.这一点用一个一般的性能测试软件就可以做到大量模拟用户并发。
#### CSRF
1. CSRF（Cross-site request forgery）跨站请求伪造；，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
2. 举例：CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。
3. 了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些欺骗信息（比如借钱之类的），如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。
4. 防御：
* 通过 referer、token 或者 验证码 来检测用户提交。
* 尽量不要在页面的链接中暴露用户隐私信息。
* 对于用户修改删除等操作最好都使用post 操作 。
* 避免全站通用的cookie，严格设置cookie的域。
#### ddos
1. 分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。
2. 一群恶霸试图让对面那家有着竞争关系的商铺无法正常营业，他们会采取什么手段呢？（只为举例，切勿模仿）恶霸们扮作普通客户一直拥挤在对手的商铺，赖着不走，真正的购物者却无法进入；或者总是和营业员有一搭没一搭的东扯西扯，让工作人员不能正常服务客户；也可以为商铺的经营者提供虚假信息，商铺的上上下下忙成一团之后却发现都是一场空，最终跑了真正的大客户，损失惨重。此外恶霸们完成这些坏事有时凭单干难以完成，需要叫上很多人一起。嗯，网络安全领域中DoS和DDoS攻击就遵循着这些思路。
### 验签
#### 协议规则
1. 传输方式：为保证交易安全性，建议采用HTTPS传输
2. 提交方式：采用POST方式提交
3. 数据格式：提交数据都为json；返回数据采用JSON
4. 字符编码：统一采用UTF-8字符编码
5. 签名算法：MD5
6. 签名要求：请求和接收数据均需要校验签名，详细方法请参考安全规范-数字签名
#### 签名算法
1. 除sign字段外，所有参数按照字段名的ascii码从小到大排序后使用QueryString的格式（即secret=yhjs&key1=value1&key2=value2…）拼接而成，空值不传递，不参与签名组串。
2. 公式：sign=Md5(原字符串).toUpperCase
3. 举例说明：deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd
4. 得到的sign=Md5(secret=yhjs&deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd).toUpperCase()=7648CE21E5FF1C9B905B3344660CC12D
5. header中的值参与验签；
#### web端
1. web端的secret传yhjsWeb
#### app客户端
1. Header中需传以下参数：deviceId(手机唯一标识，ios使用udid)、producer（android使用android.os.Build.MANUFACTURER、ios使用固定字符串apple）、channelId（渠道id，ios使用app store）、ip(手机的ip地址)、timestamp(请求的当前时间戳)、platform(android、ios、web);
2. secret=yhjsHwAdnroid520 yhjsHwIos607
#### java端
1. 对签名做验证；
2. yh:safe:cc:唯一标识-时间戳-方法名 作为key存到redis中，有效期是五分钟(存到配置文件)，值value第一次是1，第二次是2，第三次是3，如果超过3不响应该请求；
3. 拉黑机制：新增数据库 yhjs-safe :新增表 ecs_user_safe(中有字段 is_black),取过一次之后放到redis中，yh:safe:black:usernameList;
1. 如果key中包含WithoutSign,该key不参与验签;
2. 请求url的字符串，如果请求的url中包含WithoutSign,该接口不参与验签；
### 验签
#### 协议规则
1. 传输方式：为保证交易安全性，建议采用HTTPS传输
2. 提交方式：采用POST方式提交
3. 数据格式：提交数据都为json；返回数据采用JSON
4. 字符编码：统一采用UTF-8字符编码
5. 签名算法：MD5
6. 签名要求：请求和接收数据均需要校验签名，详细方法请参考安全规范-数字签名
#### 签名算法
1. 除sign字段外，所有参数按照字段名的ascii码从小到大排序后使用QueryString的格式（即secret=yh&key1=value1&key2=value2…）拼接而成，空值不传递，不参与签名组串。
2. 公式：sign=Md5(原字符串).toUpperCase
3. 举例说明：deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd
4. 得到的sign=Md5(secret=yh&deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd).toUpperCase()=7648CE21E5FF1C9B905B3344660CC12D
5. header中的值参与验签；
#### web端
1. web端的secret传yhWeb
#### app客户端
1. Header中需传以下参数：deviceId(手机唯一标识，ios使用udid)、producer（android使用android.os.Build.MANUFACTURER、ios使用固定字符串apple）、channelId（渠道id，ios使用app store）、ip(手机的ip地址)、timestamp(请求的当前时间戳)、platform(android、ios、web);
2. secret=yhAdnroid***** yhIos*****
#### java端
1. 对签名做验证；
2. yh:safe:cc:唯一标识-时间戳-方法名 作为key存到redis中，有效期是五分钟(存到配置文件)，值value第一次是1，第二次是2，第三次是3，如果超过3不响应该请求；
3. 拉黑机制：新增数据库 yh-safe :新增表 ecs_user_safe(中有字段 is_black),取过一次之后放到redis中，yh:safe:black:usernameList;
## 交互
### 攻击类型
1. sql注入；
2. 参数篡改；
3. xss攻击；
4. 防盗链；
5. 文件上传漏洞攻击；
6. cc攻击；
7. CSRF（Cross-site request forgery）跨站请求伪造；
8. ddos;
#### xss
1. 定义：XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的. 比如获取用户的Cookie，导航到恶意网站,携带木马等。
2. 防护：
* 使用HTTPS！就跟我前面《HTTP与HTTPS握手的那些事》这篇文章说的，HTTPS会在请求数据之前进行一次握手，使得客户端与服务端都有一个私钥，服务端用这个私钥加密，客户端用这个私钥解密，这样即使数据被人截取了，也是加密后的数据。
* 特殊符号过滤
## 盗链
1. 盗链是指服务提供商自己不提供服务的内容，通过技术手段绕过其它有利益的最终用户界面（如广告），直接在自己的网站上向最终用户提供其它服务提供商的服务内容，骗取最终用户的浏览和点击率。受益者不提供资源或提供很少的资源，而真正的服务提供商却得不到任何的收益。
#### cc攻击
1. 因为CC攻击来的IP都是真实的，分散的；
2. CC攻击的数据包都是正常的数据包；
3. CC攻击的请求，全都是有效的请求，无法拒绝的请求。
4. 攻击者借助代理服务器生成指向受害主机的合法请求，实现DDOS和伪装就叫：CC(ChallengeCollapsar)。
5. CC就是充分利用了这个特点，模拟多个用户（多少线程就是多少用户）不停的进行访问（访问那些需要大量数据操作，就是需要大量CPU时间的页面）.这一点用一个一般的性能测试软件就可以做到大量模拟用户并发。
#### CSRF
1. CSRF（Cross-site request forgery）跨站请求伪造；，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
2. 举例：CSRF攻击的主要目的是让用户在不知情的情况下攻击自己已登录的一个系统，类似于钓鱼。如用户当前已经登录了邮箱，或bbs，同时用户又在使用另外一个，已经被你控制的站点，我们姑且叫它钓鱼网站。这个网站上面可能因为某个图片吸引你，你去点击一下，此时可能就会触发一个js的点击事件，构造一个bbs发帖的请求，去往你的bbs发帖，由于当前你的浏览器状态已经是登陆状态，所以session登陆cookie信息都会跟正常的请求一样，纯天然的利用当前的登陆状态，让用户在不知情的情况下，帮你发帖或干其他事情。
3. 了解CSRF的机制之后，危害性我相信大家已经不言而喻了，我可以伪造某一个用户的身份给其好友发送垃圾信息，这些垃圾信息的超链接可能带有木马程序或者一些欺骗信息（比如借钱之类的），如果CSRF发送的垃圾信息还带有蠕虫链接的话，那些接收到这些有害信息的好友万一打开私信中的连接就也成为了有害信息的散播着，这样数以万计的用户被窃取了资料种植了木马。整个网站的应用就可能在瞬间奔溃，用户投诉，用户流失，公司声誉一落千丈甚至面临倒闭。曾经在MSN上，一个美国的19岁的小伙子Samy利用css的background漏洞几小时内让100多万用户成功的感染了他的蠕虫，虽然这个蠕虫并没有破坏整个应用，只是在每一个用户的签名后面都增加了一句“Samy 是我的偶像”，但是一旦这些漏洞被恶意用户利用，后果将不堪设想，同样的事情也曾经发生在新浪微博上面。
4. 防御：
* 通过 referer、token 或者 验证码 来检测用户提交。
* 尽量不要在页面的链接中暴露用户隐私信息。
* 对于用户修改删除等操作最好都使用post 操作 。
* 避免全站通用的cookie，严格设置cookie的域。
#### ddos
1. 分布式拒绝服务(DDoS:Distributed Denial of Service)攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS攻击，从而成倍地提高拒绝服务攻击的威力。通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。
2. 一群恶霸试图让对面那家有着竞争关系的商铺无法正常营业，他们会采取什么手段呢？（只为举例，切勿模仿）恶霸们扮作普通客户一直拥挤在对手的商铺，赖着不走，真正的购物者却无法进入；或者总是和营业员有一搭没一搭的东扯西扯，让工作人员不能正常服务客户；也可以为商铺的经营者提供虚假信息，商铺的上上下下忙成一团之后却发现都是一场空，最终跑了真正的大客户，损失惨重。此外恶霸们完成这些坏事有时凭单干难以完成，需要叫上很多人一起。嗯，网络安全领域中DoS和DDoS攻击就遵循着这些思路。
### 验签
#### 协议规则
1. 传输方式：为保证交易安全性，建议采用HTTPS传输
2. 提交方式：采用POST方式提交
3. 数据格式：提交数据都为json；返回数据采用JSON
4. 字符编码：统一采用UTF-8字符编码
5. 签名算法：MD5
6. 签名要求：请求和接收数据均需要校验签名，详细方法请参考安全规范-数字签名
#### 签名算法
1. 除sign字段外，所有参数按照字段名的ascii码从小到大排序后使用QueryString的格式（即secret=yhjs&key1=value1&key2=value2…）拼接而成，空值不传递，不参与签名组串。
2. 公式：sign=Md5(原字符串).toUpperCase
3. 举例说明：deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd
4. 得到的sign=Md5(secret=yhjs&deviceId=098f6bcd4621d373cade4e832627b4f6×tamp=1513302406&token=36165415151dsvd).toUpperCase()=7648CE21E5FF1C9B905B3344660CC12D
5. header中的值参与验签；
#### web端
1. web端的secret传yhjsWeb
#### app客户端
1. Header中需传以下参数：deviceId(手机唯一标识，ios使用udid)、producer（android使用android.os.Build.MANUFACTURER、ios使用固定字符串apple）、channelId（渠道id，ios使用app store）、ip(手机的ip地址)、timestamp(请求的当前时间戳)、platform(android、ios、web);
2. secret=yhjsHwAdnroid520 yhjsHwIos607
#### java端
1. 对签名做验证；
2. yh:safe:cc:唯一标识-时间戳-方法名 作为key存到redis中，有效期是五分钟(存到配置文件)，值value第一次是1，第二次是2，第三次是3，如果超过3不响应该请求；
3. 拉黑机制：新增数据库 yhjs-safe :新增表 ecs_user_safe(中有字段 is_black),取过一次之后放到redis中，yh:safe:black:usernameList;