sql注入靶场_sql注入

sql注入靶场

My first experience with SQL injection was some 20 years ago but is still very relevant today.

我第一次使用SQL注入的经验大约是20年前，但是今天仍然非常重要。

With all the advanced Database access frameworks, features, and languages out there, it is still very easy to make a simple mistake and leave your site vulnerable to SQL attacks. These vulnerabilities can be patched quite easily, as long as the programmer knows what to be aware of, and this is the reason and motivation behind today’s blog entry.

有了所有高级数据库访问框架，功能和语言，仍然很容易犯一个简单的错误，并使您的站点容易受到SQL攻击。 只要程序员知道要注意什么，就可以很容易地修补这些漏洞，这就是今天博客条目背后的原因和动机。

As a bookworm, I ran an internet search for an out-of-print book I was looking for, and one of the first results was a book trading site. “Cool”, I thought. I’ll register to the site, send out some books I have read already, and receive this book in return.

作为一个书虫 ，我在互联网上搜索了我想要的绝版书籍，第一个结果是一个图书交易网站。 我想，“很酷”。 我将注册到该站点，发送一些我已经阅读过的书，并以此作为回报。

I hit “sign up”, and as I always do, first tried to sign up with my name and an apostrophe after the name.

我点击“注册”，并且像往常一样，首先尝试用我的名字签名，然后在名字后面加上撇号。

And I saw a lovely SQL error appear:

我看到一个可爱SQL错误出现：

I now knew the site was vulnerable to attacks. Obviously, I didn’t sign up, as my personal information would be available to anyone with basic hacking knowledge. Instead, I spent about half an hour to discover the website’s owner username and password, logged into his account, grabbed his e-mail, e-mailed him all the details, and informed him that I would very much like to sign up as I love the concept of the site, but cannot because it’s completely open to hackers.

我现在知道该站点容易受到攻击。 显然，我没有注册，因为只要有基本的黑客知识，我的个人信息就可以使用。 相反，我花了大约半小时来发现网站的所有者用户名和密码，登录到他的帐户，抓取了他的电子邮件，向他发送了所有详细信息，并告知他我非常想注册，喜欢该网站的概念，但不能因为它完全向黑客开放。

Turns out the website owner paid someone to code the site for him, but the programmer apparently did not know anything about SQL injection…

原来，网站所有者付钱给某人为他编写网站代码，但是程序员显然对SQL注入一无所知……

This article assumes that as a programmer, you have a basic understanding of SQL, if

本文假设作为程序员，您对SQL有基本的了解，如果

SELECT first_name, last_name FROM members WHERE username=’adminuser’ AND password=’12345678’

Means nothing to you, read about SQL first.

对您毫无意义，请先阅读有关SQL的知识。

This sort of SQL would be generated when the site admin tries to log-in with the password 12345678

当站点管理员尝试使用密码12345678登录时，会生成这种SQL

If a row is returned, you get a “hi admin first name,” page and the user credentials are stored in memory/cookie

如果返回一行，则会显示“ hi admin first name”(嗨，管理员名字)页面，并且用户凭据存储在内存/ cookie中

If no rows are returned, login has failed, and an appropriate message is shown to the user.

如果未返回任何行，则登录失败，并向用户显示相应的消息。

But what if we try the password 1234’ ?

但是，如果我们尝试密码1234'怎么办？

The code behind the scene looks like:

幕后的代码如下：

Function (String user, String password) {Sql = “SELECT first_name, last_name FROM members WHERE username=’” + user + “’ AND password=’” + password +”’”}

The resulting SQL would be

结果SQL将是

SELECT first_name, last_name FROM members WHERE username=’adminuser’ AND password=’1234’’

Which would result in some generic SQL error.

这将导致一些通用SQL错误。

Ok, let’s fix the error — use password:

好的，让我们解决该错误-使用密码：

Password 1234’ OR password like ‘a%

Now the resulting SQL is

现在生成SQL是

SELECT first_name, last_name FROM members WHERE username=’adminuser’ AND password=’1234’ OR password like ‘a%’

Now, if the password begins with “a”, the login succeeds, otherwise it fails.

现在，如果密码以“ a”开头，则登录成功，否则将失败。

Let’s assume I discover it begins with a, I can now try like ‘aa%, like ‘ab%, and so forth..

假设我发现它以a开头，我现在可以尝试像'aa％，像'ab％，依此类推。

As I mentioned, it took me half an hour to discover the entire password, using notepad and a browser only.

正如我提到的，仅使用记事本和浏览器，我花了半个小时才找到整个密码。

So what can be done?

那该怎么办呢？

Check all user input for invalid characters! disallowing anything but [a-zA-Z0–9 -_] in a string will leave you safe enough.

检查所有用户输入的无效字符！ 禁止在字符串中使用[a-zA-Z0–9 -_]以外的任何内容，这将使您足够安全。

If user input is a number, convert it to a number, then take the string value, this will assure that it is a valid numeric value.

如果用户输入是数字，请将其转换为数字，然后采用字符串值，这将确保它是有效的数字值。

The same goes for dates, and any other values — make sure no characters can disturb your intended SQL query.

日期和任何其他值也一样—确保没有字符会干扰您想要SQL查询。

Use a prepared SQL statement (available in most languages) whenever possible. These statement are pre-compiled and so assure that only values are passed in from the user and you completely avoid any issues of your intended SQL code being changed.

尽可能使用准备好SQL语句(大多数语言都可用)。 这些语句是预先编译的，因此可以确保仅从用户传递值，并且您完全可以避免更改预期SQL代码的任何问题。

*All* checks have to be made on the BE side, never assume an FE check works, they can all be easily bypassed.

*所有*检查必须在BE端进行，从不假设FE检查有效，所有这些检查都可以轻松绕开。

This is quite easy to do and will prevent a lot of problems later on.

这是很容易做到的，以后可以防止很多问题。

Another point to think on when designing log-in mechanisms is to restrict the number of attempts, and not to always return an error message! sounds weird, right?

设计登录机制时要考虑的另一点是限制尝试次数，而不总是返回错误消息！ 听起来很奇怪，对吧？

Well, let’s think about the forgot password page for a second. Enter your e-mail address, and you get your password reset link in the mail, right? Well, yes, unless you are a hacker who wished to check if johnDoe@gmail.com signed up to this or that site. He enters the site, hits forgot password, enters Joe’s e-mail, and gets an error if Joe isn’t signed up. nice, huh?

好吧，让我们考虑一下忘记密码页面。 输入您的电子邮件地址，您会在邮件中看到密码重置链接，对吗？ 好吧，是的，除非您是希望检查johnDoe@gmail.com是否已注册该站点的黑客。 他进入站点，输入忘记密码，输入Joe的电子邮件，如果未注册Joe，将收到错误消息。 很好吧？

It gets worse though: our considerate hacker can now proceed to harvest our entire database of e-mail addresses, he just codes a simple routine trying every possible one, and leaves it running for a few days.

但是，情况变得更糟：我们体贴的黑客现在可以继续收集我们的整个电子邮件地址数据库，他只是编写了一个简单的例程来尝试所有可能的例程，并将其运行了几天。

So, DO NOT return an error in the forgot password screen, limit the number of attempts to say 3 per minute, and the same goes for the login itself.. “e-mail isn’t registered” is BAD, “password incorrect” even if the e-mail isn’t registered is much safer!

因此，请勿在“忘记密码”屏幕上返回错误，将尝试输入的次数限制为每分钟3次，登录本身也是如此。“未注册电子邮件”是错误的，“密码错误”即使未注册电子邮件也更安全！

When coding — always think of what the other side will try to do, in general, it’s best to hide internal errors and display some generic a problem occurred, try again later to the user.

进行编码时-通常要考虑另一端将要尝试的操作，通常，最好隐藏内部错误并显示出现的一般性问题，然后再向用户重试。

The less information a hacker has about your system, the harder it is to cause problems.

黑客关于您的系统的信息越少，导致问题的难度就越大。

Hope you learned something, try not to break a leg running to examine your DB code.

希望您学到了一些东西，请尽量避免检查您的数据库代码。

翻译自: https://medium.com/att-israel/sql-injection-9c8d39d6a988

sql注入靶场