一、逻辑安全
1. 什么是逻辑安全？-CSRF/CORS
CSRF（Cross-site request forgery）简称：跨站请求伪造，跟XSS攻击一样，存在巨大的危害性。在CSRF的攻击场景中，攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了，所以CSRF攻击也称为one-click attack。
CORS是一种用于在浏览器中处理跨域资源访问的机制，当一个网页尝试从一个源请求获取资源，而该资源的服务器与网页所在的源不同时，就会涉及到跨域请求，CORS通过在HTTP请求头中添加一些特定的字段信息来进行通信，以告知服务器是否支持跨域请求，通过这种方式，CORS机制使得网页能够在受限的情况下安全地进行跨域资源访问。
2. CSRF原理
HTTP是无状态协议，服务器只能根据当前请求的参数(包括Head和Body的数据)来判断本次请求需要达到的目的(Get或者Post都一样)，服务器并不知道这个请求之前干了什么事，这就是无状态协议。
但是我们现实很多情况需要有状态，比如登录态的身份信息，网页上很多操作需要登录之后才能操作。目前的解决方案是每次HTTP请求都把登录态信息传给后台服务器，后台通过登录态信息是判断用户合法性之后再处理这个请求要处理的操作。
如何让每次HTTP请求都带上登录态信息，所以就出现了Cookie。登录态Cookie是浏览器默认自动携带的，我们在浏览器上发送HTTP请求的时候，浏览器会把该域名下的Cookie带上，一并发送到服务器。那么问题就来了，浏览器不管当前发送请求的是哪个网站，在哪个页面上发送的请求，只要你请求的域名在浏览器里保存有Cookie信息，浏览器都会一并带上。
所以只要用户C曾经登录过网站A，在没有关闭浏览器的情况下打开一个黑客网页B，黑客页面发送HTTP请求到网站A的后台，会默认带上网站A的登录态Cookie，也就能模拟用户C做一些增删改等敏感操作。这就是CSRF攻击原理。
3. CSRF防护措施
a. 验证HTTP请求头
HTTP请求头会默认带上Referer字段和Origin字段，Referer记录了该请求的来源地址，Origin记录请求来源域名。通过我们通过判断这2个字段的值，可以确认该请求是否来自安全站点，以此来阻止第三方恶意请求。
由于Referer值会记录用户的访问来源地址，有些用户认为这样会侵犯到自己的隐私，特别是有些组织担心Referer值会把内网中的某些信息泄露到外网中。因此，用户自己可以设置浏览器在发送请求时不再提供Referer。当他们正常访问银行网站时，网站会因为请求没有Referer值而认为是CSRF攻击，拒绝合法用户的访问。因此推荐使用Origin校验。
b. Token机制
CSRF为什么能攻击成功？其本质原因是重要操作的所有参数都是可以被攻击者猜测到的。现在业界对CSRF的防御，一致的做法就是增加一个参数–Token。Token必须足够随机（使用足够安全的随机数生成算法），它应该作为一个“秘密”存在于服务器和浏览器中，不被第三方知晓。由于Token的存在，攻击者无法再构造出一个完整的url实施攻击。实际应用时，Token可以放在用户的Session或者浏览器的Cookie中，在提交请求时，服务器只需验证表单中的Token与用户传过来的Token(Session或Cookie中)是否一致，如果一致则认为是合法请求；如果不一致，则认为请求不合法，可能发生了CSRF攻击。
c. 在请求头中自定义属性并验证
这种方法也是使用token并进行验证，不同的是，这里不是把token以参数的形式置于HTTP请求之中，而是把它放到请求头中自定义的属性里。通过XMLHttpRequest请求封装，可以一次性给所有请求加上csrftoken这个自定义属性，并把token值放入其中。同时，通过XHR请求的地址不会被记录到浏览器的地址栏，也不用担心token会透过Referer泄露到其他网站去。
然而这种方法的局限性非常大。XHR请求通常用于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而不能进行前进、后退、刷新等操作，给用户带来不便。
d. Cookie的SameSite属性
CSRF攻击就是利用了cookie中携带的用户信息，想要防护Cookie不被第三方网站利用，我们可以通过设置Samesite属性。SameSite最初设计的目的就是防CSRF，SameSite有三个值Strict/Lax/None。
4. Cors存在的风险
a. 验证HTTP请求头
HTTP头只能说明请求来自一个特定的域，但是并不能保证这个事实。因为HTTP头可以被伪造。
所以未经身份验证的跨域请求应该永远不会被信任。如果一些重要的功能需要暴露或者返回敏感信息，应该需要验证Session ID。
b. 恶意跨域请求
即便页面只允许来自某个信任网站的请求，但是它也会收到大量来自其他域的跨域请求。.这些请求有时可能会被用于执行应用层面的DDOS攻击，并不应该被应用来处理。
例如，考虑一个搜索页面。当通过'%'参数请求时搜索服务器会返回所有的记录，这可能是一个计算繁重的要求。要击垮这个网站，攻击者可以利用XSS漏洞将Javascript脚本注入某个公共论坛中，当用户访问这个论坛时，使用它的浏览器重复执行这个到服务器的搜索请求。或者即使不采用跨域请求，使用一个目标地址包含请求参数的图像元素也可以达到同样的目的。如果可能的话，攻击者甚至可以创建一个WebWorker执行这种攻击。这会消耗服务器大量的资源。
有效的解决办法是通过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。
c. 第三方有可能被入侵
举一个场景，FriendFeed通过跨域请求访问Twitter，FriendFeed请求tweets、提交tweets并且执行一些用户操作，Twitter提供响应。两者都互相相信对方，所以FriendFeed并不验证获取数据的有效性，Twitter也针对Twitter开放了大部分的功能。
但是当如果Twitter被入侵后：
FriendFeed总是从Twitter获取数据，没有经过编码或者验证就在页面上显示这些信息。但是Twitter被入侵后，这些数据就可能是有害的。
或者FriendFeed被入侵时：
Twitter响应FriendFeed的请求，例如发表Tweets、更换用户名甚至删除账户。当FriendFeed被入侵后，攻击者可以利用这些请求来篡改用户数据。
所以对于请求方来说验证接收的数据有效性和服务方仅暴露最少最必须的功能是非常重要的。
d. 内部信息泄漏
假定一个内部站点开启了CORS，如果内部网络的用户访问了恶意网站，恶意网站可以通过COR（跨域请求）来获取到内部站点的内容。
5. Cors防护措施
a. 不信任未经身份验证的跨域请求，应该首先验证Session ID或者Cookie。
b. 对于请求方来说验证接收的数据有效性，服务方仅暴露最少最必须的功能。
c. 通过多种条件屏蔽掉非法的请求，例如HTTP头、参数等。
二、数据安全
什么是数据安全，顾名思义保证数据的安全，指保护数据不受非法或未经授权的访问、使用、泄露、修改、破坏等威胁和风险的一系列措施和技术。
开源组件、类库、工具包等，也可能存在各种安全漏洞。
如：fastjson、log4j等
开发必须牢记以下几点：
1. 禁止将api文档开放到外网如swagger-ui一类的接口调试文档，可能会将隐藏的接口暴露在外，外部攻击者可获取所有的接口以及构造规则，更容易找到存在漏洞的接口。
2. 禁止将调试接口开放到外网
如php的laravel debug页面SpringBoot actuator，均可能导致配置文件的信息直接泄露，可能涉及数据库密码、aksk等敏感信息。
3. 日志要规范
为了保障Web服务端安全开发数据安全，总结以下几点：
a.实施访问控制：通过身份认证、权限管理等手段，限制只有授权用户才能访问和操作数据。
b.加密敏感数据：对重要数据进行加密处理，确保数据在传输或存储时不被非法获取。
c.定期备份和恢复数据：建立完备的数据备份和恢复机制，确保数据在遭受攻击或损坏时能够及时恢复。
d.监控和审计：对Web服务器和Web应用程序进行实时监控和审计，及时发现安全事件并采取相应的应对措施。
e.更新和维护软件：及时更新Web服务器和其中的Web应用程序以及相关的安全软件，确保已修复安全漏洞
三、总结
时刻牢记安全的重要，安全无小事。在互联网行业中，研发人员是安全的第一道守门员，我们应该对安全持敬畏之心，在精进专业的基础上，编码安全、逻辑安全和数据安全上狠抓细节，减少安全漏洞。
