api安全笔记

约定不等于承诺〃 2023-07-07 08:39 16阅读 0赞

# api安全 #

## 什么是api? ##

application program interface

为客户端提供服务的一种方式.

当我们讨论api安全时,包括

*  信息安全: 保证信息在整个生命周期中是受到保护的
 *  网络安全:传输过程中的安全,防止第三方访问
 *  应用安全:应用设计时保证安全

api安全的目标:**CIA**

*  机密性(Confientiality): 保证信息只被预期的用户访问.
 *  完整性(Integrity):防止未授权的创建,修改和删除.
 *  可用性(Availability):api总是可用的.

### 常见的api风险:STRIDE ###

Spoofing: 欺骗.伪装成某人.

Tampering:干预.将不希望被修改的数据,消息/设置进行更改.

Requdiation:否认,拒绝承认做过的事.

Information disclosure:信息泄露.将你希望保密的信息披露出来.

Denial of service:拒绝服务.阻止用户访问信息和服务.

Elevation of privilege:越权,做了你不希望他做的事.

### 风险与安全机制的对应关系 ###

认证:(欺骗).确保用户真的是他们自己.

授权:(信息泄露/干预/越权).确保每个针对api的访问都是经过授权的.

审计:(否认).确保所有的操作都被记录,以便追溯和监控.

流控:(拒绝服务).防止用户请求淹没api.

加密:(信息泄露).确保出入api的数据都是私密的.

加密

客户端

流控

当api过载时拒绝多余的请求

认证

确保用户是他声明的身份

审计

记录谁什么时候做了什么

授权

决定一个请求是否可以被执行

api

## 限流 ##

当限流机制生效时,请求应该立即被拒绝,并返回状态码429(Too Many Request)

可以在负载均衡/反向代理上做(集群),应用上做(单体).

保证可用性

流控应该做在整个安全机制的第一位.

### 用guava做简单限流 ###

RateLimiter类

## 认证 ##

认证和登陆不是一个概念

认证每次都会执行,登陆一般只发生一次.

认证无论如何都会继续,传递到审计,最终是否生效由授权完成.

### HttpBasic认证 ###

最基础的认证,但并不是非常安全

步骤

*  认证信息: 用户名密码
 *  Base64加密认证信息,user:password进行加密
 *  放入请求头 **Authorization:Basic xxxx**

### 问题 ###

#### 各种校验 ####

##### 接口层校验 #####

接口层校验一般采用 JSR-303 进行校验,由框架层面进行校验,

##### 数据库校验 #####

在接口到数据库的传输过程中,由于业务的执行,可能导致数据异常,因此需要在数据库层面进行校验

#### 密码加密 ####

用户的密码一定要加密存储

加密算法的选择

*  使用不可逆的加密

传入的密码能否加密成记录的密码.

###### 盐 ######

为了避免相同值散列后值仍然相同的问题.

使用随机字符串做盐,并编入密文中.

#### Https访问 ####

数据在到达应用之前的安全保证.

*  验证双方身份

证书的获取方式

*  自签
 *  第三方购买

一般在网络入口设置https

## 审计 ##

在认证之后,授权之前.

日志需要持久化.

审计需要在应用的入口和出口处处理.

## Filter ,Interceptor,ControllerAdvice,AOP的关系 ##

request

response

filter

Interceptor

ControllerAdvice

AOP

Controller

filter是web规范

后续的是spring提供的过程

COntrollerAdvice一般是全局异常处理.

## 授权 ##

1.  请求是否需要认证,如果需要认证,却无法认证,则返回401.需要认证,但没有成功
2.  有没有权限.无权限则返回403,身份认证正常,但无权限.

401通过修改请求的参数可以避免,但如果是403,则无论进行何种修改都不应该绕过403.

#### 访问控制 ####

##### ACL : Access Control Lists #####

简单易用,实现容易.无法满足复杂的业务需求,不易管理.

谁能做什么直接和人挂钩.

linux就使用了acl

#### RBAC: Role Based Access Control ####

引入角色概念,简化管理.开发起来相对ACL复杂

谁能做什么,和人的角色相关

## 登陆 ##

登陆不是每一次都需要的.

不要在每一次请求中都传入用户名密码.

### 登陆的本质 ###

### 保持登陆状态的方法 ###

#### 基于token的身份认证 ####

认证信息

时效token

返回token

携带token

验证token

client

登陆服务

验证用户名密码

token store

其他服务

##### 基于cookie和session的实现 #####

优点:

*  使用非常方便

缺点

*  仅能在浏览器中使用
 *  容易被劫持
 *  需要分布式实现

cookie的发送与浏览器中的cookie的域名地址和请求路径有关

如果cookie是顶级域名,则cookie在下级域名中也会发送出去

cookie中还可以设置是否允许脚本发送,目的是为了防止跨站脚本攻击.

###### 问题: 固定session攻击 ######

1.首先登陆获取session cookie

诱骗用户使用攻击者已存在的session cookie进行登陆

用户一旦登陆,攻击者的session中存放的就算用户的信息了

攻击者

服务器

用户

处理方法:

先判断是否存在session.如果存在一个session,则让原有session失效.

api安全笔记

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关 API安全学习笔记

相关 API接口安全

相关 api安全笔记

相关 SpringCloud微服务安全（二）API安全 2-1 API安全概述

相关信息安全工程师笔记-数据库安全

相关 RESTFUL API 安全设计

相关 RESTful API安全

相关笔记--服务器安全和API接口安全性设计

相关 api接口安全浅谈

相关 Http Api安全通信