📜  DBMS 中的应用程序安全性

📅  最后修改于: 2022-05-13 01:56:15.513000             🧑  作者: Mango

DBMS 中的应用程序安全性

应用程序安全性表示在应用程序级别使用的安全预防措施,以防止窃取或捕获应用程序内部的数据或代码。它还包括在应用程序的推进和设计过程中进行的安全测量,以及随时保护应用程序的技术和方法。应用程序安全是流程、工具的学科,并致力于在整个应用程序生命周期中保护应用程序免受危险的规划。它可以帮助协会保护合作伙伴(包括客户、同事和代表)使用的各种应用程序(如继承、工作区、Web、便携式)。

应用程序安全类型:

  • 身份验证:身份验证是一种确保只有授权用户的方法。称为跨站点脚本 (XSS) 的弱点允许攻击者将客户端代码引入站点页面。攻击者可以直接访问用户的 data.rs 来控制应用程序。身份验证方法确认用户是他们所保证的人。在登录应用程序时,可以通过要求用户提供用户名和密码来执行此操作。还有多级身份验证可确保最大程度的安全性,例如,您知道的东西(密码)、您拥有的东西(手机)和您的身份(生物特征)。
  • 授权:经过身份验证后,允许用户访问和使用应用程序。用户的应用程序只有在比较用户的身份以批准访问后才被验证,因此身份验证必须始终在授权步骤之前。
  • 加密:在用户使用应用程序验证和授权后,其他安全协议可以保护数据免受威胁。在基于云的应用程序中从最终用户流向云时,加密是为了保证敏感数据的安全。
  • 日志记录:假设应用程序中发生安全漏洞,日志记录可以帮助确定谁访问了数据以及它是如何发生的。应用程序日志记录监控谁访问了应用程序以及访问了应用程序的哪些部分。
  • 应用程序安全测试:保证这些安全控制实际工作的策略。

DBMS中允许黑客驱动数据的应用程序安全的安全漏洞如下:

  • SQL 注入: SQL 注入也称为 SQLI,是黑客的典型攻击,他们利用恶意 SQL 代码控制后端数据库以获取未预期显示的数据。这是一种代码注入,也是最常用的可以破坏数据库的策略。这些数据可能包含很多东西,包括微妙的组织信息、客户记录或私人客户信息。这是一种代码注入,也是最常用的可以破坏数据库的策略。不同类型的 SQL 注入是:
    • 带内 SQLi:攻击者使用类似的通信渠道来发送攻击并累积其结果。带内 SQLi 的清晰性和生产力使其成为最广泛认可的 SQLi 攻击类型之一。
    • 推理(盲)SQLi:攻击者将信息负载发送到服务器,然后注意服务器的反应和行为以找出其结构。这种策略被称为盲 SQLi,因为信息不会从站点数据库转移到攻击者,因此攻击者无法看到有关带内攻击的数据。
    • 带外 SQLi:当 Web 应用程序使用的数据库服务器上的某些元素被授权时,攻击者可以完成这种类型的攻击。当攻击者无法利用类似的通道来发送攻击并积累数据时,或者当服务器速度过慢或不稳定而无法执行这些活动时,就会使用带外 SQLi 策略。这些方法依赖于服务器的限制来进行 DNS 或 HTTP 请求以将信息移动给攻击者。
  • 跨站点脚本:跨站点脚本 (XSS) 攻击是一种注入,其中恶意内容被注入受信任的网站。这是一个网络安全漏洞,允许攻击者了解客户端与弱应用程序的合作。它允许攻击者规避类似的开始安排,该安排旨在将各种网站相互隔离。攻击者可以利用 XSS 将恶意内容发送到毫无头绪的客户端。最终客户端的程序没有真正的方法来实现不应依赖内容,并将执行该内容。由于它认为内容来自可靠来源,因此恶意内容可以获取程序持有并与该站点一起使用的任何 cookie、会话信息或其他敏感数据。跨站点脚本 (XSS) 攻击发生在以下情况:
    • 信息通过不受信任的来源(通常是 Web 需求)进入 Web 应用程序。
    • 对于发送到 Web 客户端的动态内容,该信息会被记住,而没有被批准用于恶意内容。
  • 密码泄露:第三种漏洞被称为密码泄露。当开发人员将密码作为纯文本存储在应用程序代码脚本中时,这个漏洞会导致问题。当脚本存放在注册表中并可由 Web 服务器访问时,外部客户端就有可能访问脚本的源代码并获得对应用程序使用的数据库帐户密码的访问权限。为了避免此类问题,许多应用程序服务器将密码存储在加密结构中,服务器在将密码提供给数据库之前对其进行解密。这样的元素消除了在应用程序中将密码作为纯文本保存的要求。但是,它并不完全有效,因为解密密钥也容易被暴露。
  • 应用程序身份验证:身份验证是一种确保只有授权用户的方法。称为跨站点脚本 (XSS) 的弱点允许攻击者将客户端代码引入站点页面。攻击者可以直接访问用户的 data.rs 来控制应用程序。身份验证方法确认用户是他们所保证的人。最常用的身份验证类型包括客户端使用应用程序时应引入的纯文本密码。许多应用程序使用双因素身份验证,其中使用两个独立因素来识别客户端。在大多数此类双因素身份验证计划中,密码被用作第一个因素,一次性密码被用作第二个因素。重要的是,即使使用两因素身份验证,客户端也可能受到中间人的攻击。在这些攻击中,客户端在尝试访问应用程序的原始界面时会被重定向到虚假网页,该网页会确认来自客户端的密码,并快速利用它对原始应用程序进行身份验证。
  • 应用程序级授权:授权是服务器决定客户端是否同意使用资产或访问文档的过程。授权通常与身份验证相结合,因此服务器对提到访问权限的客户端有一些了解。有时,没有授权;任何客户都可能基本上通过请求来使用资产或访问记录。 Internet 上的大多数网站页面都不需要身份验证或授权。标准 SQL 支持授权,但不支持某些特殊类型的授权,例如所有员工都可以看到自己的工资单,但看不到公司其他人的工资单。这种类型的授权会导致 SQL 出现问题,问题是
    • 终端用户信息量减少:随着Web的发展,对数据库的访问基本上来自Web应用服务器。最终用户通常会尝试在实际数据库中没有唯一的客户端标识符,并且与应用服务器的所有用户相比,可以肯定数据库中可能只有一个客户端标识符。因此,在上述情况下不能使用 SQL 中的授权确定。
    • 缺乏细粒度的授权:授权应该是单个元组的程度,如果要批准员工只能看到自己的工资单。这种授权在当前的 SQL 标准中是不可想象的,该标准仅在整个连接或视图上授权授权,或者在确定关系或透视图的属性上授权。
  • 隐私:隐私是信息技术 (IT) 的一部分,它处理协会或个人需要弄清楚计算机系统中的哪些信息可以与第三方共享的能力。应谨慎构建访问此类私人信息的应用程序,并牢记隐私法规。维护隐私对于收集个人信息非常重要,例如临床记录、财务信息、犯罪记录、政治记录、业务相关信息或站点信息。例如,电子商务网页经常收集个人信息,如位置、电话、电子邮件和信用卡信息。此类信息可能会进行诸如从商店购买商品之类的交易。

应用程序安全风险

从大规模网络到 以 Web 应用程序为中心的数据库更改安全问题已分发。以下是一些安全风险:

  • 第一个安全风险称为跨站点脚本 (XSS),允许攻击者将客户端代码引入站点页面。攻击者可以直接访问用户的数据。
  • 一些孤立的攻击者使用拒绝服务 (DoS) 和分布式拒绝服务 (DDoS) 攻击来用不同类型的流量淹没指定服务器或支持它的框架。这种流量最终使真实用户无法访问服务器,从而使其关闭。
  • 黑客使用一种称为 SQL 注入 (SQLi) 的策略来利用数据库缺陷。具体来说,这些黑客可以发现用户的个性和密码,还可以在未经用户许可的情况下创建、修改和删除数据。
  • 当黑客对应用程序执行各种攻击并最终意外更改某些内存空间时,就会发生内存损坏。结果,该软件可以正常运行或最终关闭。
  • 当损坏的代码被引入系统内存时,就会发生缓冲区溢出。溢出缓冲区的能力会导致应用程序内存的相邻区域被数据覆盖,从而带来安全风险。