山东平台网站建设设计,python做网站设计,广州网站建设说说外链的建设,如何给网站做app数据库在Web应用程序中存储和组织数据时起着至关重要的作用#xff0c;它是存储用户信息、内容和其他应用程序数据的中央存储库。而数据库实现了高效的数据检索、操作和管理#xff0c;使Web应用程序能够向用户提供动态和个性化的内容。然而#xff0c;数据库和网络应用程序…数据库在Web应用程序中存储和组织数据时起着至关重要的作用它是存储用户信息、内容和其他应用程序数据的中央存储库。而数据库实现了高效的数据检索、操作和管理使Web应用程序能够向用户提供动态和个性化的内容。然而数据库和网络应用程序之间的通信不畅可能会导致敏感数据泄露、用户不信任、法律后果和利润损失。本文将探讨导致此类灾难的后端错误配置并了解如何确保应用程序的安全。
一、什么是SQL注入
SQL注入(SQLi)是一个漏洞它允许网络攻击者篡改Web应用程序发送给数据库的查询。当应用程序误解了用户的输入并将其视为SQL代码而不是字符串时就会发生注入。因此恶意用户可以更改预期的查询流破坏应用程序的逻辑并获得对其资源的未经授权的访问。
在大多数情况下当开发人员需要使用依赖于用户输入的参数化查询时就会出现SQLi。如果开发人员在将用户输入插入模板之前忘记对其进行适当的清理就会引入SQL注入漏洞。一个经典的SQL注入示例是使用纯字符串插值或连接来创建动态查询如下图所示。网络攻击者可以通过用SQL代码替换分页参数中的数字来注入任意SQL语句。 动态查询精心制作的字符串插值
二、什么是ORM注入?
现在开发人员很少使用原始SQL语句而是使用称为ORM的特殊框架。对象关系映射ORM是一种用作两种不同范例之间的适配器的技术关系(将数据存储在表中)和面向对象(将数据存储在对象中)。ORM所做的事情之一是在底层生成SQL代码。开发人员所要做的就是告诉ORM如何去做。
显然自动生成意味着自动转义用户提供的数据。ORM确保每个动态参数都像普通字符串一样被处理除非开发人员特别禁用清理功能。然而恶意代码的注入仍然是可能的。ORM注入是一个漏洞它允许密切协作攻击者强制ORM生成对他们有利的SQL。
考虑下面的例子。这里有一个函数它应该接受带有多个参数的对象过滤器例如:
{email:, name: user} ORM注入
但是开发人员忘记检查过滤器是否确实是一个对象以及它是否只包含安全的过滤参数。这样的错误使攻击者能够注入可用于恢复用户密码的恶意过滤器例如
password LIKE %a%
三、SQL注入真的很危险吗?
通常SQL注入可以被认为是一个严重的漏洞。在大多数情况下对网站任何部分的单个SQL注入最终都可以扩展到在数据库上运行任何查询提取和操作其数据。由于数据库通常保存着系统中最敏感的信息因此允许网络攻击者访问这些信息是毁灭性的。
以下是SQL注入如何被利用的简短列表
远程代码执行(通常通过特殊功能)读写主机上的文件。颠覆Web应用程序的逻辑提取敏感数据操纵数据拒绝服务
四、哪些类型的SQL注入是可能的?
在通常情况下有三种类型的SQL注入带内注入、带外注入和盲注入。反过来带内攻击可以是基于联合的或基于错误的而盲SQLi可以是基于布尔的或基于时间的。 五、SQL注入层次结构
如果攻击者足够幸运他们可以在后端响应中包含被破坏的SQL查询的结果。这被称为带内SQLi。带内SQLi有两种子类型 1.基于联合的SQLi攻击者能够指定他们可以读取的查询输出的位置列。 2.基于错误的SQLi当应用程序公开SQL/编程语言错误时这种类型的SQLi是可能的。在这种情况下攻击者可以分析错误消息/堆栈跟踪并推断攻击是否成功。 使用BlindSQLi网络攻击者无法看到被破坏的SQL查询的结果。然而它们有某种反馈可以帮助确定是否存在注入。盲SQLi有两种子类型 1.基于布尔的SQL攻击者可以使用SQL条件语句以某种方式修改服务器的响应。然后他们可以将这种新的反应与原来的反应进行比较并确定注入是否有效。 2.基于时间的SQLi攻击者可以将数据库的SLEEP函数与条件语句结合起来从而延迟后端响应。然后他们可以将原始响应时间与新的响应时间进行比较以确定注入是否成功。 在某些情况下攻击者可能根本无法从数据库获得任何反馈。在这种情况下它们可以强制数据库将输出重定向到另一个位置并尝试从那里读取它。这就是所谓的带外SQL注入。例如他们可以强制数据库将包含敏感信息的DNS查询发送到他们控制的DNS服务器。或者它们可以强制数据库将一些数据写入可公开访问的文件中。这种注入会影响许多数据库。
六、减轻SQLi时的常见错误
用户不应该试图为SQL输入参数提供自己的清理程序。这样做需要深入了解数据库规范和使用它们的经验。最有可能的是最终会淹没在其他人无法理解的正则表达式中并且随着数据库的发展没有人会支持清理程序。 需要记住攻击者总是试图混淆他们的SQLi有效负载将其偷运到WAF和IPS。有大量的框架可以利用SQLi为攻击者提供扭曲有效负载的脚本库。编写自定义混淆处理程序并将其与现有混淆处理程序结合使用也很容易。 考虑一下开发人员在试图净化用户输入时所犯的一些常见错误。
一个常见的误解是可以通过删除/替换SQL查询参数中的空格来避免SQLi。例如如果攻击者只能使用一个单词会造成多大的伤害?但是许多数据库将注释转换为空格因此“SELECT email FROM user”等于“SELECT/**/email/**/FROM/**/user”这是一个单词。 使用注释而不是空格的SQLMap篡改脚本
通常认为删除引号可以使参数安全但有时攻击者可以指定另一个特殊字符来定义字符串。例如PostgreSQL允许定义包含在双美元符号中的多行字符串。所以“email”等于$$ email$$。 SQLMap篡改脚本使用双美元符号代替单引号
最后但并非最不常见的错误是对数据库关键字进行非递归删除。这也很容易绕过检测因为攻击者可以在相同的关键字中间插入关键字。因此经过清理之后注入仍然存在。例如
“SELSELECTECT” - “SELECT” 用于嵌套关键字的SQLMap篡改脚本
七、防止SQL注入的正确方法
防止SQLi的第一步是使用预处理语句。允许用户定义预处理语句也是不可接受的。这里有一个使用TypeORM防止SQL注入的例子采用硬编码的模板并使用这个框架的特性来安全地插入变量 使用TypeORM编写语句
但是仅仅使用ORM是不够的。正如前面看到的业务逻辑缺陷可以允许绕过安全保护措施。SQLi修正的第二步是显式验证用户输入。如果需要一个数字可以手动将值转换为数字。如果需要URL可以手动将输入字符串转换为URL。这种方法显著降低了利用SQLi的可能性。额外的好处是将拥有更一致的数据和更少的错误。有许多库可用于声明性验证例如express-validator或class-validator。
另一件需要记住的重要事情是始终为每个应用程序创建一个专用的数据库用户。仔细阅读有关默认用户权限的文档并禁用除了对应用程序运行至关重要的功能之外的所有功能。除了数据库管理之外永远不应该将DBA帐户用于其他任何事情。默认情况下DBA帐户被授予所有可能的权限。这显著地放大了SQL注入的严重性。
最后但同样重要的是使用Web应用程序防火墙或入侵预防系统。它们能够发现并破坏SQL注入攻击甚至有一组流量规则来检测依赖SQLi的已知漏洞。当然使用WAF或IPS并不是灵丹妙药因为它们可以绕过检测。然而这种工具的存在显著提高了进行攻击所需的知识阈值。另外WAF/IPS干扰了SQLi开发自动化并提供了比传统工具更好的日志记录。
八、相关内容拓展技术前沿
近10年间甚至连传统企业都开始大面积数字化时我们发现开发内部工具的过程中大量的页面、场景、组件等在不断重复这种重复造轮子的工作浪费工程师的大量时间。
针对这类问题低代码把某些重复出现的场景、流程具象化成一个个组件、api、数据库接口避免了重复造轮子。极大的提高了程序员的生产效率。
推荐一款程序员都应该知道的软件JNPF快速开发平台采用业内领先的SpringBoot微服务架构、支持SpringCloud模式完善了平台的扩增基础满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力采用前后端分离模式前端和后端的开发人员可分工合作负责不同板块省事又便捷。
体验官网https://www.jnpfsoft.com/?csdn
还没有了解低代码这项技术可以赶紧体验学习
