应用安全_应用安全测试 - CSDN
精华内容
参与话题
  • 企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。 对于应用程序安全,需要在应用架构、代码、运维、管理等多个角度进行安全性评估,在整个应用程序生命周期...

    前言

    随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。

    对于应用程序安全,需要在应用架构、代码、运维、管理等多个角度进行安全性评估,在整个应用程序生命周期中,软件工程师们则主要负责身份验证、访问授权、进程间通信安全、代码安全、安全的管理与审计这五方面的方案落地。这五个方面中,前三个侧重于技术实现,代码安全、管理与审计则更需要规范的管理和执行,本文将着重对认证、授权、通信等技术相关内容重点介绍,管理规范相关内容仅做简单说明。

    文中以采用了微服务架构的应用程序为背景进行描述,但多数的应用程序的安全方案与是否采用微服务架构并没有强关联,如有差异的地方,文中会提出来。文中描述过程中会涉及到一些微服务架构中相关的概念名词,说明如下:

    名词 解释说明
    应用 即应用程序,本文中特指一个微服务应用
    业务系统 即传统意义上的软件系统,如:OA办公系统、个贷系统等。微服务架构中,业务系统不是个业务逻辑概念,一个业务系统由一个或多个应用(微服务)组成。
    网关 即API Gateway 是客户端访问应用的入口,后端应用的API门户。通常负责身份认证、API管理、路由、编排等等
    服务 即API,特指程序接口 ,如服务调用 即为 API调用。需注意在本文中不要与微服务、应用等概念混淆
    认证管理系统 认证管理系统(IAM),负责身份识别和访问管理,其核心业务是应用系统的访问者的注册、账号密码凭证、访问者基本信息的管理和对已注册的访问者进行合法性认证和访问授权。
    授权服务 指身份认证授权服务,在微服务架构中,通常是认证管理系统(IAM)的一个应用。认证中心具备读取"访问者"身份信息的权限。负责核实"访问者"的身份、为访问者颁发授权码、访问令牌等能力
    访问者 在安全领域统称"Principal",指应用程序功能UI或API的使用者,包含两类:1,基于登录的客户端 2,API 客户端
    API客户端 API Client 即客户端程序类型的访问者,这类客户端自身具备部分API的访问权限,不需要用户授予其访问权限。
    基于登录的客户端 Login-based Client ,用户访问服务提供者的应用程序的功能时,需要通过一个客户端交互界面来与服务提供者交互,用户需要先登录,然后由客户端代表用户身份去访问服务提供者应用程序。

    微服务架构中安全访问相关的简化版的运行视图如下:

    运行视图.png

    图中星号*标注的位置就是服务调用过程中安全访问过程中的一些需要认证鉴权的关键位置,如:内外部访问认证、令牌验证与授权、内外网通信协议等。后续章节将对这部分展开分析。

    身份认证

    多数业务功能类的应用的首要任务就是需要做身份认证。对于数据公开或新闻发布类的门户网站类应用不需要考虑这一点,他们更关注的是数据开放之前的管理和审批。

    身份认证或身份验证(Authentication),顾名思义就是对应用程序的"访问者"的身份进行验证识别。访问者分两类。

    • 基于用户登录的客户端(Login-based Client):用户访问服务提供者的应用程序的功能时,需要通过一个客户端交互界面来与服务提供者交互,用户需要先登录,然后由客户端代表用户身份去访问服务提供者应用程序。
    • API 客户端(API Client):客户端程序类型的访问者,这类客户端自身具备部分API的访问权限,不需要用户授予其访问权限。

    1. 使用认证管理系统IAM进行访问者注册认证

    不论是用户还是API客户端,在访问应用之前,均需要先到认证管理系统IAM进行注册,以创建其的身份凭证(用户账号和密码、客户端ID和密码)。有了身份凭证,才能通过认证服务的验证。

    统一认证管理系统IAM(Identity and Access Management )负责身份识别和访问管理,其核心业务是应用系统的访问者的注册、账号密码凭证、访问者基本信息的管理、对已注册的访问者进行合法性认证和访问的初级授权(获取访问者自身数据)等等。

    ​有些企业还会将组织机构、角色甚至业务功能权限数据也一并归入IAM系统管理。IAM对权限管理范围可大可小,不同企业的管理需求和力度也不一样,需要集中进行功能授权管理还是下放到业务系统中自治各有优缺点,选择合适自己的方式就好。

    2. IAM认证管理系统使用OAuth2.0进行访问者授权

    ​传统WEB应用对于用户登录访问,采用会话状态在服务端保存的方案,用户请求通常采用会话粘滞(Sticky session)或会话复制(Replication session)策略,来保持客户端和服务端的会话。为了会话共享而不得不将会话信息写入公共缓存或数据库,导致微服务应用之间产生了耦合性。

    ​微服务架构中不推荐采用服务端保存会话的方式,如果引入状态管理不是必要的,那么应用尽量保持无状态运行。推荐使用另外一种基于访问令牌的模式,这种模式下应用中不需要保存会话状态,并且API客户端和基于登录的客户端均方便使用访问令牌。微服务架构推荐使用OAuth2.0 授权协议来搭建IAM系统。Spring 体系可以基于Spring Security OAuth实现授权服务器和客户端。

    在本文的上下文中,面向的是企业基于微服务的总体架构进行方案设计,企业整体架构中,默认认证体系方案为企业统一认证而非业务系统各自认证(此方案的前提条件)。OAuth2.0本身是为三方授权而设计的,而在本方案中讨论的是企业内部应用的整体认证和授权,不存在第三方。因此本方案中基于OAuth2.0实现的授权服务可以简单理解为仅为IAM统一认证管理系统中的“账号管理应用资源提供者”做授权,并且默认实现为认证通过自动授予已登录账号数据的读写权限,不在登录通过后与用户交互确认是否同意授权。其他业务系统作为资源提供者的授权则是系统管理员预置好的授权,也不需要由用户登录时决定是否授权。这个OAuth2.0的使用场景可能与其他OAuth2.0相关资料或授权框架默认实现有所不同,请大家注意区分。

    OAuth协议中定义了四种角色:

    • 资源所有者
      能够许可对受保护资源的访问权限的实体。当资源所有者是个人时,它被称为最终用户。
    • 资源服务器
      托管受保护资源的服务器,能够接收和响应使用访问令牌对受保护资源的请求。
    • 客户端
      使用资源所有者的授权代表资源所有者发起对受保护资源的请求的应用程序。术语“客户端”并非特指任何特定的的实现特点(例如:应用程序是否是在服务器、台式机或其他设备上执行)。
    • 授权服务器
      在成功验证资源所有者且获得授权后颁发访问令牌给客户端的服务器。

    角色分析:

    • 对于前面提到的API 客户端,自身具备API访问权,不需要用户授权,因此在OAuth角色对应时,它既是客户端又是资源所有者
    • 微服务架构中Web应用一般采用前后端分离的模式,前端为基于浏览器访问的纯前端应用,网关作为应用程序的入口,此时网关本身可以代表OAuth中的客户端身份访问服务提供端应用的功能接口
    • 在微服务架构中,负责颁发访问令牌的授权服务通常在IAM系统中实现
    • 资源服务器,在微服务架构中,所有的业务系统中的服务功能提供者都是资源服务器,也包括IAM系统的账号、组织机构服务、资源权限管理服务等等

    在OAuth2.0授权协议中,主要定义了四种许可类型:授权码许可、简单许可、密码凭据许可和客户端凭据许可,详细请参见规范内容:rfc6749 - The OAuth 2.0 Authorization Framework

    下面我们根据访问者类型,分别推荐合适的授权方案。

    2.1 API客户端作为访问者,使用客户端凭证许可

    典型的API客户端如批量调度系统、物联网设备程序等,通常不需要用户登录授权就可以自动运行。使用客户端凭证许可类型比较适合。

    客户端凭证.png

    上图为OAuth2.0规范标准流程图,结合此场景中,对应OAuth2.0中的角色,API客户端作为OAuth2.0的客户端、IAM则为授权服务器。

    1. (A) API客户端与授权服务器IAM进行身份验证并请求访问令牌。
    2. (B) 授权服务器IAM对API客户端进行身份验证,如果有效,颁发访问令牌。客户端存储访问令牌,在后 续的请求过程中使用。如果令牌过期或失效或需要重复此流程再次申请访问令牌。

    其他说明:

    1. 此类应用通常不具备与用户交互的UI,无需用户授权,具备保证客户端凭证安全的能力
    2. 此类应用后端需要具备通过https访问授权服务器的能力
    3. 此类应用或设备需要具备存储Access Token的能力

    2.2 基于登录的客户端作为访问者,使用授权码许可

    2.2.1 Web 应用

    OAuth2.0 协议中提出前端单页Web应用可以用简单许可模式,但简单许可模式有些局限性,令牌到期就需要重新登录授权,不支持令牌刷新,用户体验较差。很多使用简单授权的应用为了改善用户体验会颁发一个长期的令牌几天甚至几周。

    如果有条件使用授权码模式,支持刷新令牌则是一个更好的选择。对访问令牌时间较短如2分钟,刷新令牌为一次性令牌有效期略长如30分,如果存在已作废的刷新令牌换取访问令牌的请求,授权端点也能够及时发现做出相应入侵处理,如注销该用户的所有刷新令牌。在保持良好用户体验的同时还兼顾了部分安全性。

    本场景以微服务架构中常见的前后端分离Web应用作为示例,前端是单页应用,网关作为Web后台是服务提供端应用功能入口,也可作为OAuth2.0的客户端,让前端Web应用能借助网关实现授权码交换。因此在微服务架构中,即便是纯前端单页应用类的Web应用,仍可以用基于网关交互的授权码模式获取访问令牌。其他非前后端分离的混合Web应用自身就是客户端,不需要借助网关交换访问令牌。

    授权码.jpg

    上图为OAuth2.0规范标准流程图,结合此场景对应OAuth2.0中的角色,用户是资源所有者、浏览器为用户代理、网关作为被授权的客户端、IAM则为授权服务器。

    1. (A) 网关通过引导浏览器开始流程授权流程,重定向到统一认证中心的登录页面。
    2. (B)用户输入密码登录,授权服务器验证用户身份,并确认用户是否授权网关的访问请求。
    3. (C)用户授权后,认证中心根据之前网关注册时提供的回调地址,引导浏览器重定向回到网关。重定向URI包含授权码
    4. (D)网关通过包含上一步中收到的授权码和网关自身凭证从授权服务器IAM的请求访问令牌。
    5. (E)授权服务器IAM对网关进行身份验证,验证授权代码,并确保接收的重定向URI与网关注册时的URI相匹配。匹配成功后,授权服务器IAM响应返回访问令牌与可选的刷新令牌给网关。

    其他说明:

    1. 为了前端会话保持,访问令牌由网关在响应时返回到前端,存储到前端存储空间,如Cookie(不超过4k)、Local Storage、Session Storage等。
    2. 访问令牌失效后,网关根据自己的客户端凭证+刷新令牌一起发送授权服务器,获取新的访问令牌和刷新令牌,并再返回响应中将访问令牌写入到用户浏览器的存储中
    3. 授权码模式中,用户的凭证(用户名、密码)是用户通过浏览器与授权服务交互,并不经过网关, 安全性最好。

    2.2.2 移动App

    个人移动设备上安装的原生App本身具备实现授权码流程的能力,不需要借助网关实现授权码流程。认证通过后网关仅负责校验访问令牌即可。

    移动App-授权码.jpg

    移动App实现登录重定向通常可以采用如下方式:

    • 模拟web端,使用移动端浏览器与WebView
    • 使用URI scheme与Intent在应用间跳转

    移动端App的运行环境是不可信的,容易被恶意App入侵的风险,包含如下两种情况:

    1. 重定向过程中的回调URL参数,容易被恶意App占用URL Scheme或者监听localhost端口截取。
    2. 运行环境不可靠,移动App不具备安全保存客户端秘钥的能力,而使用授权码获取访问令牌时需要校验客户端秘钥。

    基于上述风险和问题,移动App基于授权码获取访问令牌的流程需要进行优化解决,rfc规范中建议的实现方案是移动App授权流程采用使用带有PKCE支持的授权码模式。PKCE, 全称Proof Key for Code Exchange,即保护授权代码授权。这其实是通过一种密码学手段确保恶意第三方即使截获Authorization Code或者其他密钥,也无法向认证服务器交换Access Token。

    经过PKCE改进的授权码、访问令牌交换过程示意图如下:

    PKCE.png

    上图为PKCE模式下授权码申请和交换访问令牌的过程,说明如下:

    1. (A) 移动App客户端创建并保存名为code_verifier的随机秘钥串,并将秘钥字符串加密转换的结果t(code_verifier)称为code_challenge,将转换后的code_challenge以及转换方法一并发送到授权服务中。
    2. (B) 授权服务返回授权码并记录code_challenge和转换方法t_m
    3. (C) 移动App客户端收到授权码后,将授权码和code_verifier秘钥串发送到授权服务器,用以申请访问令牌。
    4. (D) 授权服务器根据转换方法t_m 转换code_verifier 并与步骤A中收到的code_challenge比较,如果一致则返回访问令牌,否则拒绝非法请求。

    第三方无法根据code_challenge推导出code_verifier,因为code_challenge采用了不可逆加密方式。只有移动App客户端自己才知道这两个值。因此即使恶意App截获了code_challenge和授权码,也无法换取访问令牌避免了安全问题。要实现这种移动App的PKCE授权码模式,出移动App自身外,还需要IAM的授权服务器基于标准的授权码流程扩展配合实现。

    关于移动App安全认证的详细内容请参考官方规范:

    2.3 高度信任的特权类客户端,可以使用资源所有者密码凭据许可

    用户密码凭据.png

    上图为OAuth2.0规范标准流程图,结合此场景中,对应OAuth2.0中的角色,用户是资源拥有者、特权应用是客户端、IAM提供授权服务器

    • (A)用户提供给特权App用户名和密码。
    • (B)特权App将用户凭据提交给授权服务器IAM,申请访问令牌
    • (C)授权服务器IAM 验证用户的凭证,如果有效,颁发访问令牌给特权App。特权App对授权服务器颁发的访问令牌、刷新令牌进行存储和更新。

    其他说明:

    • 虽然是特权App,但App中不要持久化保存用户密码,仅登录时使用
    • App负责保存Access Token 、Refresh Token

    3. 使用API 网关作业务系统访问入口,负责验证访问令牌

    访问者能够访问的接口通常是两类:身份认证API、应用功能类API。

    • 身份认证类API:即登录认证相关的API。为了避免用户、客户端凭证泄漏第三方(除IAM、访问者之外为第三方),身份认证类API或UI建议由IAM系统直接开放给访问者调用进行身份认证。
    • 应用功能类API:功能实现来自服务提供者,通过网关开放给访问者。网关是访问应用API的入口。

    用户登录认证由IAM授权服务器配合用户资源服务负责。认证成功后,IAM访问者颁发访问令牌。后续对应用功能的访问过程中,均须携带访问令牌以表明访问者的身份。

    3.1 由网关负责客户端身份验证

    网关作为业务系统的API入口,当面向外网的访问者时网关还是内外网的分界,访问令牌验证理应由网关负责,不应该将令牌验证的事情交给服务提供者。 网关负责验证既能避免未经验证的请求进入内网,又能够简化服务提供端的代码,服务提供端无需处理不同类型客户端的验证。实际上好处还不只这些,在网关可以统一做流控无需应用端重复建设类似功能;系统内部调试、变更敏捷,减少了跨组织交互。

    网关验证访问令牌有两种方案:网关委托认证服务验证、网关直接验证,说明如下:

    • 方案一:网关委托授权服务验证,每次收到请求后,网关均将访问令牌发送到IAM认证服务进行认证,认证通过后才允许继续访问。

    网关委托IAM校验令牌.png

    1. 客户端成功认证后,使用UUID类型的访问令牌调用网关上的服务
    2. 由于UUID类型令牌不包含客户端的信息,网关需要委托IAM认证服务校验令牌
    3. 令牌检查合法后,将请求路由到服务提供者
    4. 应用中也无法解析令牌,需要根据UUID令牌到IAM中获取用户信息
    • 方案二(推荐):网关直接验证,要求网关能识别IAM颁发的令牌,这种模式推荐用 JWT令牌,网关需要具备解析校验JWT加密的访问令牌的能力。

    网关直接校验令牌.png

    1. 客户端成功认证后,使用JWT令牌调用网关上的服务
    2. 网关自己直接解密JWT令牌进行校验
    3. 令牌检查合法后,将请求路由哦到服务提供者
    4. 应用受到请求后,如果需要更多权限信息,如果可以根据Token去权限管理服务获取权限信息(非必须步骤,需要时添加)。

    上述两方案中,方案一的令牌是无业务含义的身份标识字符串,每次收到请求网关都去IAM认证,对IAM认证服务的性能压力较大。方案二中IAM颁发的令牌中包含部分客户端或用户信息,使用JWT加密,IAM将验证方式或SDK提供给了负责认证的网关。对于IAM来说,减少了每次请求令牌认证带来的通信次数,减轻了IAM的压力。

    推荐采用方案二实现令牌检查,需要注意的是方案二中的JWT令牌中仅包含必要的信息即可,不要放太多的角色权限信息。后续功能中需要额外的信息时,可以根据令牌再去IAM中获取。如果令牌中存放了很多的权限数据,一旦后台的授权数据发生变化,令牌中的权限数据与实际IAM的权限会存在不一致的问题,只能强制用户下线重新登录。

    JWT令牌是防篡改的,但并不加密,如需要存储到浏览器存储中,建议采用JWT+JWE方式进行令牌加密。令牌中存放必要少量数据即可,避免滥用。多数服务器通常会对Http header、cookie长度做限制。

    3.2 系统内部应用是否通过网关?

    我的答案是不需要,否则太麻烦了。通常网关是独立团队负责,API变更发布、内部联调验证还得跨团队协调实在不可行。推荐系统内直通不走网关,系统之间访问必须走网关。要做到这一点,应用也需要实别请求来源进行客户端认证,这种认证方案没必要太复杂,应用只应该允许信任的网关和系统内部应用程序访问其服务,不允许系统外部请求绕过网关直接调用,因此,需要在网关和系统内部应用之间这个小范围内建立信任,常见方案有两种:

    • 方案一,内部令牌:系统内的应用在发布接口到网关时,提供一个系统内部共享的令牌给网关和系统内所有应用,接收到请求时检查请求头中是否包含系统内信任的令牌, 如果包含可信任令牌,那么就允许访问,否则就拒绝
    • 方案二,系统内保密令牌+网关证书单独认证:系统内用保密令牌交互就是方案一,只是内部令牌不共享给网关,网关用公私钥证书签名方式与域内系统建立信任,由网关生成公私钥证书,颁发公钥给各个系统,网关调用服务提供者时,请求头中带上用私钥签名的令牌,应用收到请求以后用网关发布的公钥验证其令牌。

    方案一优点是实现简单,缺点是安全级别略低,常见的企业架构中,网关和业务系统会是不同团队甚至不同的厂商负责开发维护,内部令牌共享给了其他团队负责的网关,存在一定的风险。方案二相比方案一略复杂一点,安全性更高,系统内互通用内部令牌,系统和网关认证使用了网关提供的安全令牌检查方式。两种方案可根据实际需求选择。

    访问授权

    通过认证的API客户端能够访问网关开发的所有API吗?通过认证的用户能够调用所有API吗?通过认证的用户允许调用修改订单的接口,那么他能修改所有人的订单吗?

    很显然绝大多数场景下上述三个问题答案都是"不能"。在绝大多数业务场景中除了对访问者的身份认证之外,我们还需要再进一步控制权限。

    1. API客户端访问网关接口时,网关需进行API权限控制

    如果访问者是API客户端时,API调用的权限需由网关进行控制。建议采用先订阅再访问的授权模式,网关应该仅允许API客户端访问其订阅过的API 。 具体实现方法就是绝大多数网关都会提供的基于API Key控制API访问的方式。

    需要注意的是,仅使用API key的访问控制是不够的。API Key是在网关订阅API时生成的一串唯一编号,并不具备识别客户端身份的能力。就好比以前买火车票是不实名的,谁拿到火车票,都可以乘坐对应车次。火车票实名制之后,首先需要核验身份证,核验通过后才能购票乘车。如果证票不符,则不允许乘车。

    将客户端认证和API Key配合进行访问认证和权限校验才是个更安全的方案。

    API 权限控制.png

    上图为访问令牌结合API Key的认证鉴权示意图,说明如下:

    • 客户端1获取了API Key 但其没有合法的访问令牌,如果不允许匿名访问,则网关会拒绝客户端1访问,返回错误码401表示客户端未通过认证;

    • 客户端2拥有了合法的访问令牌,但其API Key不合法,网关在客户端2认证检查通过后,检查API Key,发现其权限不足,则返回错误码403表示客户端的权限不足;

    • 客户端3拥有合法的客户端访问令牌和API Key访问网关上的服务,网关认证、鉴权通过之后,将请求路由到实际的服务提供端,最终发回正常响应数据。

    2. 用户访问应用功能时需要进行权限控制

    用户访问的功能权限或数据权限不要交给网关管控,原因是网关仅能支持API Path授权,而实际需要控制的用户权限有很多,如菜单、API、数据等。如果由网关控制用户权限,管少了不满足需求,管多了就要耦合太多应用数据。

    因此推荐用户权限由业务系统自行管理维护和控制。每个业务系统内部如果需要控制用户权限,可以建设一个基础权限框架,负责管理权限数据,并提供访问请求拦截和权限检查的SDK给其他应用。

    也有部分企业权限管理要求较高,将系统内部的基础权限框架抽取为独立的权限管理服务,由独立团队维护该服务,采用分布式部署+权限缓存的方式保障性能。这样做的好处是权限模型统一、容易对权限变更进行审批控制和审计。缺点是跨团队交互,变更流程复杂。

    关于权限管理,是业务系统自治或是集中管控,根据企业自身的需求特点决定即可。

    通信安全

    通信安全的方案就是基于传输过程加密的方式,常见的选择就是使用Https协议通信。

    微服务架构体系中,逻辑层面上外部请求接入都是通过网关作为入口,网关作为内外网的分界,实际部署上,网关本身也是多实例分布式的高可用部署形态,前面架设有一个负载均衡F5或nginx,用来对外提供Https协议接入和路由转发,而网关内部就是企业内网,默认是可信任的,内网的系统之间的通信会采用更轻量级的HTTP协议。此方案中微服务换成SOA,把网关换成ESB,就是传统的SOA架构中的安全通信方案,本质上没有区别。

    示意图如下,

    内外网通信协议.png

    为什么用了https就能保证通信安全呢?https是http+ssl,采用密码学手段对通信报文做了加密,使得报文无法被篡改,做到了安全传输,从而保障了通信安全。关于https原理和负载均衡器证书配置相关资料网络上有很多,请大家即用即查。

    代码安全

    • 敏感配置加密:上述各种服务安全场景和方案聊了那么多,大家发现保存好令牌、密钥、密码是一切安全的前提。这些东西千万不能外泄。要保证密码不泄露的办法就是做好敏感数据保密,技术手段上则要求存储密码、凭证的地方(配置文件和数据库表)需要加密存储。如:配置文件中的数据库口令、数据表中存放的密码数据等

    • 代码质量管理:建议在开发期对于编码规范进行制定,还可以通过工具进行辅助检查和控制,如开源的代码质量管理工具Sonar,可以支持多种程序语言,方便的与编译构建工具集成如Maven,在代码进入正式提交对应分支前就将一些安全问题在前期预防,如SQL注入等。

    • 运行时安全扫描:测试阶段,可以通过安全扫描软件,如AppScan 等工具对业务系统的前后端功能进行扫描,检查系统漏洞并即时修复。尽量减小在上线运行后出现安全事故的风险。

    管理审计

    运维管理安全方面,根据安全需求,要有安全相关的管理规范和工具支撑,对系统管理、权限分配和关键数据进行严格管控,并做好操作审计日志记录。

    比如很多安全级别高的行业或企业中如军工类,对于业务系统的修改、权限管理审计做了严格的流程规范和功能支撑。如典型的三员管理,采用三权分立、互相制约的思路,包含系统管理员、安全管理员、安全审计员三个角色,互相能看到对方的信息,将业务过程分成不同的段,每段由对应人员负责,不让任何人掌控全局。

    审计工作是非常重要的一环,没有任何系统和流程是绝对安全的。关键的操作、数据变化等审计日志需要完整记录。一旦发生问题,可以通过审计日志排查分析追踪。常见内容举例如下:

    • 对于敏感数据项(如:密码)的访问
    • 客户端注册、用户认证授权过程
    • 权限的授予和废除
    • 关键数据的变更、删除
    • 审计功能的启动和关闭
    • 其他关键API、命令的访问

    以上这些审计方面的工作中,如果是基于API相关的审计信息记录,如边界交互报文数据,建议基于统一的技术框架进行记录管理。一些内部实现方法,则可以采用接口、方法上加注解,AOP拦截后记录的方案。其他情况可根据实际需求设计审计数据存储的方案。

    参考引用



    作者:郝炎峰
    链接:https://www.jianshu.com/p/23b5c5cdbd8d
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • 应用系统安全管理

    千次阅读 2017-04-05 17:14:38
    应用系统的安全管理 1 身份鉴别 1.1 应用系统采用专用的登录控制模块

    应用系统的安全管理

    1 身份鉴别

    1.1 应用系统采用专用的登录控制模块对登录用户进行身份标识和鉴别,具有用户身份唯一标识和鉴别信息复杂度检查功能,保证应用系统中不存在重复的用户身份标识,身份鉴别信息不易被冒用。

    1.2登录失败采取结束会话方式,根据非法登录次数为4次,当网络登录连接超时自动退出等。

    1.3系统应有“退出”功能,允许用户终止当前会话。

    1.4系统应启用身份鉴别,用户身份唯一性检查、用户身份鉴别信息复杂度检查以及登录失败处理功能,并根据安全策略配置相关参数。

    1.5用户身份鉴别信息中的密码信息,应符合以下要求:

     1)每半年修改一次密码;

    2)不包含全部或部分用户名(任意连续3个字符);

    3)长度至少为8个字符;

    4)至少包含有英文大写字母、小写字母、数字、特殊字符这四种类型字符中的3种字符。

    5)有效期最长为6个月。

    1.6应对同一个用户采用2种或2种以上组合鉴别技术实现用户身份鉴别。

    2 访问控制

    2.1应提供访问控制功能,依据安全策略控制用户对文件、数据库等客体的访问。

    2.2访问控制的覆盖范围应包括与资源访问相关的主体、客体及他们之间的操作。

    2.3应由授权主体配置访问控制策略,并严格限制默认账号的访问权限。

    2.4应授予不同账号为完成各自承担任务所需的最小权限,并在他们之间形成相互制约的关系。

    2.5应具有对重要信息资源设置敏感标记的功能。

    2.6应依据安全策略严格控制用户对有敏感标记重要信息资源的操作。

    3安全审计

    应保存业务日志,保证业务操作不被抵赖,并通过日志安全分析操作行为,发现安全问题。安全日志审计应达到以下要求:

    1)在服务器端日志记录客户端的IP地址、认证者身份、操作时间、操作类别和操作结果等信息;

    2)在服务器端记录程序错误信息日志;

    3)对日志信息的访问权限要做访问控制策略;

    4)对重要日志进行专门的采集、备份、管理,定期对日志进行安全分析,生成审计报表。

    4剩余信息保护

    4.1应保护用户鉴别信息所在的存储空间被释放或在分配给其他用户前得到完全清除,无论这些信息是存放在硬盘还是内存上。包括但不限于应用系统内存中的剩余用户信息,FTP剩余用户信息,数据库剩余用户信息,均应该先清除或改写后在进行删除。

    4.2应保证系统内的文件、目录、数据库记录等资源所在的存储空间被释放或重新分配给其他用户前得到完全清除,包括但不限于应用系统内产生的剩余文件资源、关联的FTP资源和数据库记录资源、均应该先清除或者改写后在进行安全删除,防止数据恢复工具对其进行恢复。

    5通信完整性和保密性

    5.1 主要通过VPN或者绑定IP地址来保证通信过程中数据的保密性。WEB程序对于重要数据及指令的传输应进行通信加密和校验。另外用户通过HTTPS访问应用系统,对传输的数据内容进行双向加密。

    5.2对于应用系统数据的通信和传输,各系统均应采取如下的方式来确保通信的完整性:

    发送端应使用MD5或级别更高的散列算法作为指纹,将数据加密,然后在接收端进行比对。

    6抗抵赖性

    6.1 对系统用户的每一次登录和其对系统重要模块的操作均记录日志,因此能够实现抗抵赖性。

    6.2应具有在请求的情况下为数据原发者或接受者提供数据原发证据的功能。

    6.3应具有在请求的情况下为数据原发者或接受者提供数据接收证据的功能。

    7软件容错

    7.1 对于系统用户错误性操作,系统需能给出提示或提供自动纠正功能,为校验数据输入的准确性,系统需采取代码校验,数据逻辑关系校验等方法。对于系统用户的非法操作,系统需具备自我保护能力,自动处理此类问题,让非法输入不能对系统运行造成任何影响。另外系统需具有对错误类型进行分类的能力,且需要根据不同的错误类型给予用户不同的错误提示信息。

    7.2在故障发生时,系统能够继提供一部分功能,并实施必要的措施将故障影响降到最低。应提供自动保护功能,当故障发生时自动保护当前所有的状态,保证系统能够进行恢复。

    8资源控制

    8.1当系统通信双方中的一方在60s内未作出任何响应,另一方会自动结束会话。可以手工配置参数,对系统的最大并发连接数进行限制,并禁止单个账户的多重并发会话。

    8.2限制系统多个最大并发会话数,对一个时间段内可能的并发会话连接数进行限制。

    8.3应能够对一个访问账户或一个请求进程占用的资源分配最大限额和最小限额。

    8.4应能够对系统服务水平降低到预先规定的最小值进行检测和报警。

    8.5应提供服务优先级设定功能,并在安装后根据安全策略设定访问账户或请求进程的优先级,根据优先级分配系统资源。

    展开全文
  • 云上应用安全

    千次阅读 多人点赞 2020-10-06 13:13:03
    目录课程介绍1.WEB应用安全概述web应用安全问题示例web应用安全问题OWASP十大安全漏洞列表(2017年)web组成部分及web安全分类应用安全防护方法应用安全防护工具2.通过阿里云WAF保护应用安全什么是阿里云WAF?阿里云...

    课程介绍

    1.WEB应用安全概述

    web应用安全问题示例

    在这里插入图片描述

    web应用安全问题

    在这里插入图片描述

    OWASP十大安全漏洞列表(2017年)

    在这里插入图片描述

    web组成部分及web安全分类

    在这里插入图片描述

    应用安全防护方法

    在这里插入图片描述

    应用安全防护工具

    在这里插入图片描述

    2.通过阿里云WAF保护应用安全

    什么是阿里云WAF?

    在这里插入图片描述

    阿里云WAF的产品功能

    在这里插入图片描述

    阿里云WAF的竞争优势

    1.资源能力

    在这里插入图片描述

    2.数据模型

    在这里插入图片描述

    阿里云WAF工作原理

    在这里插入图片描述以www.taobao.com为例

    在这里插入图片描述

    阿里云WAF应用防火墙安全监测流程

    在这里插入图片描述

    阿里云WAF接入方法

    在这里插入图片描述

    WAF的不同版本

    在这里插入图片描述

    3.SQL注入及防护

    什么是SQL注入攻击?

    在这里插入图片描述

    SQL注入攻击的现象

    在这里插入图片描述
    如上图,当监控识别车牌号,保存进数据库时,会执行drop database语句,删除此记录

    SQL注入的过程

    在这里插入图片描述

    SQL注入产生的原因

    在这里插入图片描述

    SQL注入攻击语句举例

    在这里插入图片描述

    SQL注入防护手段

    在这里插入图片描述

    通过阿里云WAF防护SQL注入

    在这里插入图片描述防护模式:发现注入危险便拦截
    预警模式:发现注入,只警告,不拦截

    在这里插入图片描述

    4.网站防篡改

    什么是网页防篡改

    在这里插入图片描述

    网站篡改态势(2006年)

    在这里插入图片描述

    网站篡改的动机

    经济、政治、宗教、炫耀
    在这里插入图片描述

    网页篡改的特点及危害

    在这里插入图片描述

    网站被篡改的原因

    在这里插入图片描述

    网站被篡改的过程

    在这里插入图片描述

    网站篡改的基本原理

    在这里插入图片描述

    通过阿里云WAF防网页篡改

    在这里插入图片描述

    5.CC攻击防护

    什么是CC攻击

    在这里插入图片描述

    CC攻击的原理及危害

    在这里插入图片描述

    防御CC攻击的方法

    在这里插入图片描述

    通过阿里云WAF防止CC攻击

    在这里插入图片描述

    在这里插入图片描述

    6.阿里云WAF的业务风控安全实践

    关键业务欺诈场景

    在这里插入图片描述

    1.垃圾注册

    在这里插入图片描述

    2.登录撞库

    在这里插入图片描述

    3.营销作弊

    在这里插入图片描述

    ……

    通过阿里云WAF进行数据风控

    在这里插入图片描述

    风控原理

    在这里插入图片描述

    风控流程

    在这里插入图片描述

    展开全文
  • Web应用安全认知

    2018-09-26 10:58:30
    阿里云大学课程:Web应用安全认知 课程介绍: 目前云计算环境下的应用主要以Web应用为主,本认证课程旨在帮助学员了解Web应用的主要威胁,以及对常见的攻击,如:SQL注入攻击、XSS攻击、文件上传攻击等,有一定的...

    阿里云大学课程:Web应用安全认知

    课程介绍:

    目前云计算环境下的应用主要以Web应用为主,本认证课程旨在帮助学员了解Web应用的主要威胁,以及对常见的攻击,如:SQL注入攻击、XSS攻击、文件上传攻击等,有一定的理解。这样才能更好的在开发或运维过程中预防和处理这些攻击,以及减少带来的影响。

    课程目标:

     了解Web应用的主要威胁

     理解SQL注入攻击的分类、方式和防御方法

     理解XSS注入攻击的分类、方式和防御方法

     理解文件上传攻击的分类、方式和防御方法

    课时列表:

    课时1:课程目标和内容介绍

    课时2:OWASP十大Web弱点介绍

    课时3:SQL注入攻击和防护介绍

    课时4:SQL注入攻击实践

    课时5:跨站脚本攻击和防护介绍

    课时6:跨站脚本攻击实践

    课时7:文件上传攻击和防护介绍

    课时8:文件上传攻击实践

    课时9:【在线实验】初识SQL注入攻击

    课时10:【在线实验】初识XSS攻击

    开始学习:Web应用安全认知

    阿里云大学首页:阿里云大学

    展开全文
  • 应用安全基础

    2018-07-26 14:33:24
    应用安全是一种可供开发人员、测试人员与管理人员在其整个开发过程可用的多层方法论。我们基于计算机的培训课程(CBT)为开发人员、测试人员、项目经理和架构师准备了软件安全开发的最新知识,以培养员工的安全意识,...
  • 企业应用安全

    2019-10-29 15:26:44
    一、我们身边的安全问题 存储问题、通信问题、B2C(B2B)交易问题、服务交互问题、移动应用服务问题、内部人为问题 二、应对安全问题的武器 2.1 安全技术目标 保密性、完整性、可用性、可靠性、抗否认性、可控性...
  • 安全性信息应用到以下对象时发生错误”解决办法要夺取所有权时,点“安全”添加用户并允许所有权限后点击“应用”, 一直“无法保存对。。。(文件夹名)权限所在的更改。拒绝访问”啊 必须先点击“高级”,把...
  • Java Error: 应用程序已被Java安全阻止

    万次阅读 2015-03-02 14:31:07
    我的Java版本是Java 8 Update 31打开Oracle E-Business Suite报Java安全性错误:错误内容:应用程序已被Java安全阻止出于安全原因,应用程序现在必须满足“高”或“非常高”安全设置的要求或属于“例外站点”列表的...
  • 0x00前言 对于windows的用户权限、用户组权限等问题,windows 的文件/文件夹的所属权限控制一点也不逊色于linux/Uinx, 并且不是一般人所能可以轻松控制的。下面就来说说,我们在...2 【安全】-->>【高级】-->>【所有
  • 说明:应用程序试图执行安全策略不允许的操作。要授予此应用程序所需的权限,请与系统管理员联系,或在配置文件中更改该应用程序的信任级别。 如图:   可是原来还可以正常使用,后来我判定肯定是iis设置...
  • 当运行程序的时候有这样的弹窗出现时    到控制面板中的程序里面选择Java ...在弹窗的安全中进行设置,把安全级别调到高或者中,或者在编辑站点列表中添加url也可以,点击应用和确认后设置生效  ...
  • 安全信息应用到以下对象时发生错误文件夹拒绝访问 今天把 windows 2008 服务器上的权限误操作把一些用户删除,同时也把管理员用户弄为只能读取了.然后想删除相应的目录和文件就没有权限了. 查阅相关资料都没有解决....
  • 问题: 解决方法:控制面板→JAVA→安全,将级别调至中(最低)。
  • 应用软件的不安全性对我国信息技术发展产生了重大威胁,近年来我国频繁发布信息安全相关政策,鼓励安全可靠技术和产业生态发展,以应对这种局面。 安可产业要实现技术自主可控,需要在四个层面逐步实现:基础硬件...
  • 这是腾讯应用宝后台收到有部分APP12月25日前要安全评估报告,然后前往》全国互联网安全管理服务平台然后在里面碰到的吧 发现魅族12月23日也要提交这个东西 目前已知的需要安全评估报告的安卓市场有金立、应用宝、...
  • 在包含Applet标签的页面,运行中较高的jdk版本(例如jdk1.7或jdk1.8),会弹出【应用程序已被安全设置阻止】的安全警告框(如下图),这是由于oracle在jdk1.7(主要涉及到jdk7u21, jdk7u45, jdk7u51版本)中引入了对...
  • 安全性信息应用到以下对象时发生错误”解决办法 要夺取所有权时,点“安全”添加用户并允许所有权限后点击“应用”, 一直“无法保存对。。。(文件夹名)权限所在的更改。拒绝访问”啊 必须先点击“高级”,把...
  • 出于安全和性能方面的原因,此Windows 模式只运行应用商店中经过验证的应用,这有助于保护电脑井让其保持平稳运行。 x:\xxxx\...\x.exe 仍要运行这一未验证的应用?查看炒作方法 给出2个选择,一个是 复制到...
  • 安裝SQL2012 出現規則"Microsoft .NET應用程式安全性"產生警告 解决方法 http://crl.microsoft.com/pki/crl/products/MicrosoftRootAuthority.crl
  • 问题1:IE浏览器中Java小程序无法运行 原因: 装了jdk但是没有装jre或者jre...问题2:应用程序已被安全设置阻止 解决:去设置java安全级别 其他可能原因:IE安全性太高,禁止小程序运行 解决:更改IE安全设置
1 2 3 4 5 ... 20
收藏数 1,642,029
精华内容 656,811
关键字:

应用安全