Это механизм управления вредоносами/ботнетом. Можно провести анализ вредоноса и выявить эти домены или алгоритм генерации таких доменов, после чего зарегистрировав такие домены можно использовать их для перехвата и нейтрализации ботнета. Такая операция называется sinkholing.
Такие домены используют как триггеры: вредонос стучит по определенному адресу и, к примеру, получает там новые инструкции. В данном случае при получении ответа от домена, вредонос, согласно заложенной инструкции, прекращал сканирование и выявление новых жертв для распространения.
Если вы используете PDO — это прекрасно. Обратите внимание — статья не о методах защиты, а о методах ее обхода. Существует защита от инъекций — это и PDO и другие методы, указанные в комментариях. Можно вообще не использовать БД — вообще самый радикальный метод =) К сожалению не все придерживаются такого мнения, поэтому SQL-инъекции все еще так распространены/
Prepared statements / parameterized queries are generally sufficient to prevent 1st order injection on that statement*. If you use un-checked dynamic sql anywhere else in your application you are still vulnerable to 2nd order injection.
2nd order injection means data has been cycled through the database once before being included in a query, and is much harder to pull off. AFAIK, you almost never see real 2nd order attacks, as it is usually easier for attackers to social-engineer their way in.
You can accomplish a 2nd order injection attack when you can cause a value to be stored in a database that is later used as a literal in a query. As an example, let's say you enter the following information as your new username when creating an account on a web site (assuming MySQL DB for this question):
' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '
Scenario #1: Imagine a mobile banking app that connects to an XML API at the bank for account information and
performing transactions. The attacker reverse engineers the app and discovers that the user account number is passed as part of the authentication request to the server along with the username and password. The attacker sends legitimate
credentials, but another user’s account number, gaining full access to the other user’s account.
Scenario #2: Imagine a public API offered by an Internet startup for automatically sending text messages. The API
accepts JSON messages that contain a “transactionid” field. The API parses out this “transactionid” value as a string and
concatenates it into a SQL query, without escaping or parameterizing it. As you can see the API is just as susceptible
to SQL injection as any other type of application. In either of these cases, the vendor may not provide a web UI to use these services, making security testing more difficult.
We announced the “sana” release EOL a few months ago along with its public repositories. We’ve given a few months grace and are now finally purging the “sana” repositories from our servers. For anyone who still needs them, they can be found archived at old.kali.org.
2nd order injection means data has been cycled through the database once before being included in a query, and is much harder to pull off. AFAIK, you almost never see real 2nd order attacks, as it is usually easier for attackers to social-engineer their way in.
You can accomplish a 2nd order injection attack when you can cause a value to be stored in a database that is later used as a literal in a query. As an example, let's say you enter the following information as your new username when creating an account on a web site (assuming MySQL DB for this question):
' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '