sql注入利用_SQL注入:这是什么?原因和利用

sql注入利用_SQL注入:这是什么?原因和利用

2023年8月1日发(作者:)

sql注⼊利⽤_SQL注⼊:这是什么?原因和利⽤sql注⼊利⽤摘要 (Summary)Many security vulnerabilities are discovered, patched, and go away forever. Some linger and continue to plague softwaredevelopment and will continue to do so for years to come. Setting aside social engineering and non-technical attacks, SQLinjection remains one of the top security threats to our data, as well as one of the most misunderstood.许多安全漏洞被发现,修补并永久消失。 有些⼈会持续困扰软件开发,并将在未来⼏年继续这样做。 除了社会⼯程和⾮技术攻击之外,SQL注⼊仍然是对我们数据的最⼤安全威胁之⼀,也是最容易被误解的问题之⼀。This article takes a modern look at SQL Injection and the many ways in which it persists, despite our knowledge into what itis, what causes it, and how to eliminate it. We’ll also discuss misconceptions and myths that often hinder our securityefforts along the way.尽管我们对SQL注⼊是什么,导致它的原因以及如何消除它有所了解,但本⽂还是对SQL注⼊及其保留的许多⽅式进⾏了现代化的研究。我们还将讨论误解和误解,这些误解和误解通常会阻碍我们⼀路安全⼯作。什么是SQL注⼊? (What is SQL Injection?)Definitions vary amongst professionals, but I prefer the broadest one possible: SQL Injection is any attempt to rununauthorized code on a SQL Server via an authorized path. Unauthorized code includes absolutely anything from securitycommands to string searches to schema changes. The authorized path allows us to exclude traditional hacking, as well associal engineering and other exploits that clearly are not relevant here.专业⼈员之间的定义不尽相同,但我更喜欢最⼴泛的定义:SQL注⼊是通过授权路径在SQL Server上运⾏未授权代码的任何尝试。 未经授权的代码包括从安全命令到字符串搜索到架构更改的所有内容。 授权路径使我们可以排除传统的⿊客⼿段以及社会⼯程和其他与此处显然不相关的漏洞。SQL injection is a subset of an even larger exploit known as an injection, which also includes application code, webcomponents, networking hardware, and the other various components that make up the framework of an 注⼊是称为注⼊的更⼤漏洞利⽤的⼦集,它还包括应⽤程序代码,Web组件,⽹络硬件以及组成应⽤程序框架的其他各种组件。This threat is the most frequent and consistently rated top security exploit in the history of database software. Despiteyears of research, identification, and attention, SQL injection persists and continues to plague organizations via unprotectedendpoints.该威胁是数据库软件历史上最频繁且始终被评为最⾼的安全漏洞。 尽管经过多年的研究,识别和关注,SQL注⼊仍然存在,并继续通过不受保护的端点困扰组织。For our work, we will consider a SQL injection attempt successful if a user can access any data or SQL Server componentsthat they are not normally authorized to access.对于我们的⼯作,如果⽤户可以访问通常⽆权访问的任何数据或SQL Server组件,我们将认为SQL注⼊尝试成功。SQL注⼊的来源 (Sources of SQL Injection)SQL injection requires some entry point to execute. Some common endpoints include:SQL注⼊需要⼀些⼊⼝点才能执⾏。 ⼀些常见的端点包括:动态SQL (Dynamic SQL)This is often mistaken as the only source of SQL injection, which can be detrimental to security efforts. Dynamic SQLprovides the ability to splice variables into TSQL at runtime, allowing us to accomplish tasks that otherwise could be time-consuming or inefficient. This makes it a valuable tool, but one where its users need to ensure that each of those variablesis cleansed appropriately prior to use.这通常被误认为是SQL注⼊的唯⼀来源,这可能对安全性⼯作不利。 动态SQL提供了在运⾏时将变量拼接到TSQL中的功能,从⽽使我们能够完成可能耗时或效率低下的任务。 这使其成为⼀种有价值的⼯具,但它的⽤户需要确保在使⽤之前适当清理每个变量。Consider the following TSQL:考虑以下TSQL:DECLARE @Sql_Command NVARCHAR(MAX);DECLARE @Search_Criteria NVARCHAR(MAX);

SELECT @Sql_Command = ' SELECT * FROM WHERE ame = ''';

SELECT @Search_Criteria = 'Edward'; -- This text is captured by a form field within an application. SELECT @Sql_Command = @Sql_Command + @Search_Criteria + ''''; EXEC (@Sql_Command);It’s a simple script that searches a table for anyone with a first name matched by the variable

@Search_Criteria. If thisvariable is being populated via a web form or some open input, then there are a multitude of ways it could be abused. Somecommon tactics are to:这是⼀个简单的脚本,它在表中搜索名字与变量@Search_Criteria匹配的任何⼈。 如果通过Web表单或某些开放输⼊来填充此变量,则可以通过多种⽅式使⽤它。 ⼀些常见的策略是:Close the string and enter your own TSQL关闭字符串并输⼊您⾃⼰的TSQLUse special characters to augment a LIKE comparison, such as %, [], or insert regex使⽤特殊字符来增强LIKE⽐较,例如%,[]或插⼊正则表达式Input an empty search输⼊空搜索Use UNION ALL to append additional TSQL to the original search query使⽤UNION ALL将其他TSQL附加到原始搜索查询Use comments to eliminate any TSQL on the same line as the dynamic SQL使⽤注释消除与动态SQL相同的所有TSQLThe following is an example of TSQL and the results that can be gotten if the inputs have no protection:以下是TSQL的⽰例,如果输⼊没有保护,则可以得到结果:DECLARE @Sql_Command NVARCHAR(MAX);DECLARE @id NVARCHAR(MAX) = '3';DECLARE @password NVARCHAR(128) = ''' UNION ALL SELECT * FROM rd WHERE '''' = ''';

SELECT @Sql_Command = ' SELECT * FROM rd WHERE ssEntityID = ' + @id + ' AND PasswordHash = ''' + @password + '''';EXEC (@Sql_Command);The intention is a query that returns data for a given user ID and password, but since there are no protections on eitherinput, the TSQL can easily be hacked into returning additional data from the table.⽬的是查询返回给定⽤户ID和密码的数据,但是由于任⼀输⼊都没有保护,因此TSQL可以很容易地被⿊客⼊侵以从表中返回其他数据。Being able to get a list of usernames, tables, passwords, or any related data can be quite dangerous, even if that data isincomplete. User names can be used to intentionally fail logins and lockout users. Information about schema can be used todetermine other ways to attack a server and ultimately steal data.即使没有完整的⽤户名,表,密码或任何相关数据的列表,也很危险。 ⽤户名可⽤于故意使登录失败并锁定⽤户。 有关架构的信息可⽤于确定攻击服务器并最终窃取数据的其他⽅式。URL字符串的修改 (Modification of URL Strings)While most modern web sites protect against this, URL hacking is still one of the most common ways in which someoneattempts to gain access to data. This method is hard to detect, requires little skill, and determining success or failure isrelatively quick.尽管⼤多数现代⽹站都对此加以保护,但是URL⿊客攻击仍然是⼈们试图获取数据访问权的最常见⽅式之⼀。 这种⽅法难以检测,需要的技能很少,并且确定成功或失败的速度相对较快。If a URL contains search strings, security descriptors, or other sensitive components, then an application needs to validateURL contents prior to processing them. In addition, the application should obscure any URL contents that might be used togain undesired app information, such as primary key IDs or entity names.如果URL包含搜索字符串,安全描述符或其他敏感组件,则应⽤程序需要在处理URL内容之前对其进⾏验证。 此外,应⽤程序应遮盖所有可能⽤于获取不需要的应⽤程序信息的URL内容,例如主键ID或实体名称。Maintaining and monitoring weblogs can be an arduous task, but can provide valuable insight into areas in which hackersare trying to maliciously access a given site. Alerting on these logs can give us advance notice of potential attacks and thedetails of how they are being performed, as well as their origin.维护和监视Web⽇志可能是⼀项艰巨的任务,但可以提供有价值的洞察⼒,以了解⿊客试图恶意访问给定站点的领域。 在这些⽇志上发出警报可以使我们提前通知潜在的攻击以及如何进⾏攻击的详细信息以及其来源。⽹络/申请表 (Web/Application Forms)Any place where users can enter freeform data should be given careful attention. This is the source of most SQL injectionattacks. Hackers play the role of quality assurance and will enter every odd combination of characters, symbols, or datalength in an attempt to trigger an error or unexpected behavior.⽤户在任何可以输⼊⾃由格式数据的地⽅都应给予特别注意。 这是⼤多数SQL注⼊攻击的根源。 ⿊客扮演着质量保证的⾓⾊,他们会输⼊字符,符号或数据长度的所有奇数组合,以试图触发错误或意外⾏为。I’m curious about what happens when special characters are entered into these text fields. Are they treated like a string (asthey should be) or do they interfere with TSQL or app code, causing unexpected behavior?我对在这些⽂本字段中输⼊特殊字符会发⽣什么感到很好奇。 是否像对待字符串⼀样(应有的对待),或者它们会⼲扰TSQL或应⽤程序代码,从⽽导致意外⾏为?In this scenario, there are enough protections in place to ensure that my attempts at triggering errors or breaking TSQLstrings would fail. By greatly restricting what characters are allowed, we can head off SQL injection before it has a chance torear its ugly head.在这种情况下,有⾜够的保护措施可以确保我触发错误或破坏TSQL字符串的尝试失败。 通过极⼤地限制允许使⽤哪些字符,我们可以在SQL注⼊有机会抬起丑陋的头之前阻⽌它。员⼯滥⽤受限访问权限 (Employee Abuse of Limited Access)While we never want to consider internal employees as potential bad actors, we need to accept that in an organization largeenough, someone may eventually resort to bad behavior, given a good enough opportunity. A login that has limited serveraccess may be able to exploit SQL injection to gain additional access that normally would not be allowed.尽管我们从不希望将内部员⼯视为潜在的不良⾏为者,但我们需要接受的是,在⾜够⼤的组织中,如果有⾜够的机会,某⼈最终可能会诉诸不良⾏为。 具有受限服务器访问权限的登录名可能能够利⽤SQL注⼊来获得通常不允许的其他访问权限。Securing against SQL injection removes this avenue of attack and protects an organization from within. This is valuable in aworld full of social engineering, phishing, and other attacks that may go beyond the simplicity of a single maliciousemployee. A hacker with control over app or database access for an internal resource may gain quite a bit of power that theemployee didn’t even know they had. We want this access to be minimized as much as possible, and the many protectionswe implement to counter SQL injection greatly assist in this challenge!防⽌SQL注⼊的安全消除了这种攻击途径,并保护了组织免受内部攻击。 在⼀个充满社会⼯程,⽹络钓鱼和其他攻击的世界中,这很有价值,这可能不仅仅是单个恶意员⼯的简单性。 可以控制内部资源对应⽤程序或数据库访问的⿊客可能会获得很多员⼯甚⾄不知道⾃⼰拥有的权⼒。 我们希望尽可能减少这种访问,我们为抵制SQL注⼊⽽实施的许多保护措施极⼤地帮助了这⼀挑战!错误讯息 (Error Messages)There are a few things more dangerous than exposing error messages in an application. If you are using an app and see thefollowing, what do you think?有⼏件事⽐在应⽤程序中公开错误消息更危险。 如果您使⽤的是应⽤程序,请参阅以下内容,您认为呢?Some people might move on and ignore this, but any hacker knows that the exposure of this error message accomplishes 2tasks:某些⼈可能会继续前进⽽忽略了这⼀点,但是任何⿊客都知道暴露此错误消息可以完成2个任务:1. It provides some information about the application, database, and schema via the error details它通过错误详细信息提供有关应⽤程序,数据库和架构的⼀些信息。2. It shows us that errors are not trapped correctly and that there may be an opportunity to inject SQL at the error’ssource它向我们表明错误没有被正确捕获,并且可能有机会在错误源处注⼊SQLError messages should always be trapped, whether they be SQL, application, or web errors. Once caught, we can log themand provide a friendly (and less-specific) message to the user.错误消息应始终被捕获,⽆论它们是SQL错误,应⽤程序错误还是Web错误。 ⼀旦被捕获,我们就可以记录它们并向⽤户提供友好(且不太具体)的消息。如何利⽤SQL注⼊? (How can SQL Injection be exploited?)Once an entry point is established, a hacker’s actions will only be limited by the security of the user they are operating examples of unauthorized use include:⼀旦建⽴了⼊⼝点,⿊客的⾏为将仅受到其操作⽤户的安全性的限制。 未经授权使⽤的⼀些⽰例包括:Modifying TSQL statements to return additional data修改TSQL语句以返回其他数据Modify stored procedures, functions, or other database schemas修改存储过程,函数或其他数据库模式Test for the existence of database or server objects, such as tables or users测试是否存在数据库或服务器对象,例如表或⽤户Alter passwords or permissions更改密码或权限Access components outside of SQL Server, such as server or storage infrastructure访问SQL Server外部的组件,例如服务器或存储基础结构Delete, steal, alter, encrypt, or attempt to ransom data from within the database删除,窃取,更改,加密或尝试从数据库内部勒索数据A sneaky hacker will do this to a different server or service to introduce a distraction偷偷摸摸的⿊客将对其他服务器或服务执⾏此操作,从⽽引起⼲扰SQL注⼊的常见原因 (Common Causes of SQL Injection)No one intentionally leaves behind security holes that can be exploited with SQL injection. There are many reasons whythese security holes come about, and oftentimes they are not because we simply wrote bad code. Here is a shortlist of themost common causes of SQL injection:没有⼈故意留下安全漏洞,可以通过SQL注⼊加以利⽤。 造成这些安全漏洞的原因有很多,⽽通常不是因为我们只是编写了错误的代码⽽已。 以下是SQL注⼊最常见原因的清单:旧代码,旧代码或惰性代码 (Old, Legacy, or Lazy Code)Sometimes code was secure enough or adequate when it was written, but as time passed and technology changed, what wassecure 10 years ago is no longer acceptable.有时代码在编写时是⾜够安全或⾜够的,但是随着时间的流逝和技术的变化,⼗年前的安全性已不再被接受。As we write new code and create new features, we need to also review old code and features to ensure that things that areold are not also becoming antiquated. Unused or unneeded code should also be removed as it is the most likely to receivezero attention in the future. This balance helps ensure that all code stays secure and relevant when faced with the test oftime.在编写新代码和创建新功能时,我们还需要查看旧代码和功能,以确保旧事物也不会过时。 也应删除不使⽤或不需要的代码,因为它将来最有可能受到零关注。 这种平衡有助于确保所有代码在经过时间考验时都保持安全性和相关性。过时/未修补的应⽤程序 (Outdated/Unpatched Applications)Making use of unsupported or legacy software or features introduces security holes that may not be patched or caught asquickly as they would with modern software.利⽤不受⽀持的或遗留的软件或功能会带来安全漏洞,这些漏洞可能⽆法像使⽤现代软件那样被Swift修补或捕获。Running patched and modern versions of software are critical to avoiding security exploits, including SQL uously monitoring for new security vulnerabilities and reacting as needed is an important step towards avoidingunnecessary surprises.运⾏补丁程序和现代版本的软件对于避免安全漏洞(包括SQL注⼊)⾄关重要。 持续监视新的安全漏洞并根据需要做出React是避免不必要的意外的重要⼀步。安全假设 (Security Assumptions)Often, we are led to a false sense of security due to the isolation of different application teams or environments. If we areled to believe that an application’s web forms are protected against injection by default, then we might be lax whendeveloping stored procedures or other database objects.通常,由于隔离了不同的应⽤程序团队或环境,导致我们产⽣了错误的安全感。 如果我们被认为默认情况下会保护应⽤程序的Web表单不被注⼊,那么在开发存储过程或其他数据库对象时我们可能会松懈。We should practice optimal security whenever possible and never assume that a high level of security elsewhere will alsoprotect us. Applications change and the assumptions that were true in the past or present may not be true in the assumptions eventually lead to compliance and security auditing failures anyway, and provide no benefit beyondsaving a little bit of time now.我们应该尽可能地实践最佳安全性,并且永远不要认为其他地⽅的⾼安全性也可以保护我们。 应⽤程序发⽣了变化,过去或现在真实的假设在将来可能不正确。 这些假设最终都会导致合规性和安全审核失败,并且除了现在节省⼀点时间之外没有其他好处。⽆法分层安全 (Failure to Layer Security)The idea that security is a wall and that surrounding servers and applications in security measures can protect from hackersis no longer valid. More accurately, we should view application security like our homes: full of lots and lots of glass windowsthat can easily be broken.安全是⼀堵墙,采⽤安全措施保护周围的服务器和应⽤程序可以免受⿊客攻击的想法不再有效。 更准确地说,我们应该像对待家⼀样查看应⽤程序的安全性:充满了很多很容易被打破的玻璃窗。The optimal way to secure an organization’s data is to have layers of security around it. Have a secure database serverthat is accessed by a secure application server that is accessed by a secure web server. Each of these devices is attached tosecure networking devices and monitored by services that can alert when things go awry. The end result is a system whereit takes significant effort to access data, to the point where such efforts would be sufficient enough to trip alerts and warnan organization that something bad is going on.保护组织数据的最佳⽅法是在其周围具有安全层。 有⼀个由安全应⽤程序服务器访问的安全数据库服务器,该应⽤程序服务器由安全Web服务器访问。 这些设备中的每⼀个都连接到安全的⽹络设备,并由可以在出现问题时发出警报的服务进⾏监视。 最终结果是⼀个系统,在该系统上需要花费⼤量精⼒来访问数据,以⾄于这样的努⼒⾜以触发警报并警告组织某些不良情况正在发⽣。Within our personal control will be whatever components we manage, which are likely to be database servers. Build serversas securely as possible and never assume that other application components will shield you from bad actors.在我们的个⼈控制范围内,是我们管理的任何组件,很可能是数据库服务器。 尽可能安全地构建服务器,并且永远不要认为其他应⽤程序组件会使您免受不良⾏为的影响。漏洞利⽤ (Exploits)How SQL injection is used against up is very much up to the creativity or cruelty of a hacker. With unauthorized access to adatabase server, the level of severity of the attack will be measured by:如何使⽤SQL注⼊抵制攻击很⼤程度上取决于⿊客的创造⼒或残酷性。 在未经授权访问数据库服务器的情况下,攻击的严重程度将通过以下⽅式衡量:How long did the attack last before it was detected? How long after detection?在检测到攻击之前持续了多长时间? 检测后多长时间?Was any unauthorized data viewed, downloaded, modified, or stolen?是否查看,下载,修改或窃取了任何未经授权的数据?Were any other systems accessed via the attack?是否通过攻击访问了其他系统?What are the repercussions of the attack? What is the impact on customers or consumers?这次袭击有什么影响? 对客户或消费者有什么影响?In the event of a breach, these and many other questions will be asked. The goal will be to fully understand a hack and itsimplications. In addition, privacy and compliance policies will be reviewed. If the hack also breached these agreements, thenthe complexity of the situation could be many orders of magnitude higher than it previously was. GDPR, HIPAA, EU-USPrivacy Shield, Corporate privacy policies, and more all have an impact on a business and the level of security offered, aswell as the necessary reaction when an exploit or breach is discovered. Under many agreements, it is necessary to disclosevulnerabilities, even if there is no evidence of a breach.发⽣违规时,将询问这些和许多其他问题。 ⽬的是充分理解⿊客及其含义。 此外,还将审查隐私和合规政策。 如果⿊客也违反了这些协议,那么情况的复杂性可能会⽐以前⾼出多个数量级。 GDPR,HIPAA,欧盟-美国隐私保护盾,公司隐私政策等等,都会对业务和所提供的安全级别产⽣影响,并在发现利⽤或破坏⾏为时做出必要的React。 根据许多协议,即使没有证据表明存在漏洞,也有必要披露漏洞。Most organizations now have security officers and teams that maintain complete knowledge of all business agreements,compliance agreements, and laws regarding data privacy and security. International organizations will have far greater andmore complex needs as the laws of each country will need to be considered when determining how to operate. Manycompanies will choose to build their organization around the most stringent of requirements as a way to simplify operationsand avoid the need to have completely different business models for each country-country relationship.现在,⼤多数组织都有安全管理⼈员和团队,可以完全了解所有业务协议,合规性协议以及有关数据隐私和安全性的法律。 国际组织的需求将越来越⼤,越来越复杂,因为在确定如何运作时需要考虑每个国家的法律。 许多公司会选择按照最严格的要求建⽴组织,以简化运营并避免为每个国家/地区之间的关系建⽴完全不同的业务模型。What can attackers do? Here are some examples:攻击者可以做什么? 这⾥有些例⼦:Download unauthorized data下载未经授权的数据Delete/modify data删除/修改数据Permanently destroy data/backups永久销毁数据/备份Long-term monitor a system长期监控系统Infect systems with viruses or malware⽤病毒或恶意软件感染系统Alter security to allow/disallow access as deemed fit by the hacker更改安全性以允许/禁⽌⿊客认为合适的访问Encrypt/steal/alter data and hold it for ransom加密/窃取/更改数据并保存以进⾏勒索Publicly shame an organization via a web or social media hack通过⽹络或社交媒体⿊客公开羞辱组织Use data to infiltrate an organization or its business operations使⽤数据渗透组织或其业务运营If any of this sounds outlandish or more likely to be the contents of a James Bond movie, then we’d be sorely mistaken. Allof these scenarios have been the result of SQL injection attacks, and have happened many, many times.如果这听起来像是奇特的东西,或者更像是詹姆斯·邦德电影的内容,那么我们就会⾮常误解。 所有这些情况都是SQL注⼊攻击的结果,并且发⽣了很多很多次。The largest SQL injection attack to-date was on Heartland Payment Systems in 2008. The SQL injection attack was used togain access to credit card processing systems. The attack began in March, 2008, but was not discovered until January,2009. The company was unable to do business for 5 months afterward and was fined $145 million as compensation forfraudulent payments made.迄今为⽌,最⼤SQL注⼊攻击发⽣在2008年的Heartland Payment Systems上。SQL注⼊攻击⽤于获得对信⽤卡处理系统的访问权限。攻击始于2008年3⽉,但直到2009年1⽉才被发现。该公司在5个⽉后⽆法开展业务,并因欺诈性付款⽽被罚款1.45亿美元。Not all details of hacks and breaches are revealed to the public, so there likely are many more than we know about to its most prevalent years, from 2010-2015, it has been estimated that over 2/3 of all companies and governmentagencies were vulnerable to SQL injection.并⾮所有的骇客和违规细节都向公众披露,因此到⽬前为⽌,可能还有很多我们不知道的事情。 在从2010年到2015年的最流⾏的年份中,据估计,所有公司和政府机构中有超过2/3易受SQL注⼊攻击。In general, older systems are targeted first under the assumption that an organization that does not stay up-to-date withsoftware is more likely to be negligent on security. The top-attacked database platforms are Oracle, PostgreSQL, MySQL,and MongoDB. Within each platform, the rate of attacks increased with age. Having newer software versions not onlyprovides more modern security options, but it discourages hackers, who typically are looking for easy/low-risk targets.通常,较旧的系统⾸先要针对的⽬标是,⼀个不及时了解软件的组织更可能对安全性有所疏忽。 攻击最严重的数据库平台是Oracle,PostgreSQL,MySQL和MongoDB。 在每个平台内,攻击率随年龄增长⽽增加。 拥有较新的软件版本不仅提供了更现代的安全性选项,⽽且还阻⽌了通常会寻找容易/低风险⽬标的⿊客。我们下⼀步要去哪⾥? (Where Do We Go Next?)With an understanding of what SQL injection is and its causes, we can begin to formulate strategies to detect and prevent is our ultimate goal and one that is critical to data security and is one that affects any platform where data is stored,whether in SQL Server, MySQL, NoSQL, or some other. In our next article, we will continue this discussion into one where weattack this problem proactively, reducing the chances that we will be put on the defensive during a data breach.了解什么是SQL注⼊及其原因之后,我们可以开始制定策略来检测和预防它。 这是我们的最终⽬标,对数据安全⾄关重要,并且会影响存储数据的任何平台,⽆论是在SQL Server,MySQL,NoSQL还是其他平台中。 在下⼀篇⽂章中,我们将继续进⾏讨论,以期我们能主动地解决此问题,从⽽减少在数据泄露期间被置于防御状态的机会。进⼀步阅读 (Further Reading)sql注⼊利⽤

发布者:admin,转转请注明出处:http://www.yc00.com/news/1690836937a441766.html

相关推荐

发表回复

评论列表(0条)

  • 暂无评论

联系我们

400-800-8888

在线咨询: QQ交谈

邮件:admin@example.com

工作时间:周一至周五,9:30-18:30,节假日休息

关注微信