Заобикаляне на удостоверяването чрез SQLI

Помислете за класическия случай на SQL удостоверяване чрез инжектиране.
Целта е да се развие „правилно“ мислене или не „правилно“. Приложението използва следната класическа конструкция за проверка на потребителя при удостоверяване:

Тоест, ако съществува потребител с посоченото име и (И) парола, тогава всичко е наред - пропуснете.
И за да заобиколим удостоверяването, имаме няколко опции.
Първо изпращане в двете полета "„ИЛИ 1 =“ 1", И тогава логиката в софтуера ще бъде нещо подобно:

Нека разгледаме по-отблизо това.
Опция 1.
Разчита на сравняване на множество низове.
Например изразът "'aaa' = 'aaa' = 'aaa'" е възможен. И този израз ще ни се върне вярно. И дори такъв израз също ще бъде верен "'aaa' = 'bbb' = 'ccc'".
Защо е това и къде е логиката? Съгласен съм, странно поведение на MySQL. Вероятно и вие се интересувате?! В мрежата можете да намерите следното обяснение:
Да предположим, че имаме израза "'aaa' = 'bbb' = 'ccc'". MySQL го прави да изглежда като "('aaa' = 'bbb') = 'ccc'". И прави първото сравнение: aaa не е bbb, така че е невярно. Въпреки че, за да бъдем по-точни, това не е напълно невярно (по отношение на типовете), а 0. Което също е често срещана практика при отливането на типове.
И сега имаме израза "0 = 'ccc'", който, логично, трябва отново да е фалшив. Тъй като 0 е цяло число, а ccc е низ, MySQL трябва да преобразува последния в числова стойност. Но MySQL също преобразува ccc в нула, защото смята, че това е най-близката числова стойност. В резултат на това имаме сравнението "0 = 0".

---