TryMe, говориш глупости младеж. Всеки поне леко запознат с тази тематика - свалянето на сайтове, знае че без ти да си му казал името на таблицата, може да се открие(прочете). Достатъчни са малки умения и добро боравене със заявките. Да не говорим, че вече е пълно с програми и се навъдиха хиляди хахорчета.
Дори да ползваш mod_security отново си уязвим (до някаква степен) при неправилно написан скрипт. Например, преди време на уеб сървъра ми инсталирах Mod_security, нарочно си написах бъгливи скриптове, позволяващи SQLi, RFI и LFI. Целта ми беше да видя дали, ще мога да се възползвам от дупките и доколко mod_security може да предотврати такива атаки. Идеята на mod_security, не е нещо толкова уникално - не са открили топлата вода. Имаме rulesets съдържащи регулярни изрази, които хващат различни типове атаки. Има подобно нещо в GreenSQL с изключение на това, че там се анализират заявките. Уникалното в случая, че е направено като Apache modules.
Първото, което тествах беше SQLi. Мамка му! Все още има голям брой уязвими уеб приложения .. Въпреки, че някой ден всичко ще е минало и тези уязвимости ще бъдат рядкост.
Примерен, уязвим код. Бъгът е след WHERE клаузата на заявката, нямаме санитизиране на входни данни.
$query = mysql_query("SELECT column, column2 FROM table WHERE id=$_GET['id'];");
while ($row = mysql_fetch_array($query)) {
echo "$row[0] , $row[1]";
}
с проста SQL структура;
CREATE TABLE `table` (
`id` int(11) default NULL,
`column` varchar(10) default NULL,
`column2` varchar(10) default NULL
)
Всеки втори би използвал стария познат трик ?id=1 OR 1=1 - тук mod_security го хвана.. Но ако имаме: ?id=1 OR 1!=2 не го хваща. Извода както казах по-горе е, че ако имаме написан бъгав код скрипт, mod_security няма да ни предпази от листване на колоните в таблицата. А, ако имаме лични данни? К'во правим?
SQL операторите като INSER, SELECT, UPDATE ги хваща и блокира. Всеки би опитал да открие броя на полетата в реулзтата с ORDER BY 10-- и т.н. И това минава. В крайна сметка отново можем да "прескочим" Mod_security и бихме могли да се сдобием с имената на полетата от $query, ако използваме procedure analyse() т.е. ?id=1 procedure analyse()
Ще върне резултат:
test.table.column
test.table.column2
Ако attack vector-а е след WHERE клаузата, няма да има успех хахора. Обаче.. ако имаме join-ване на таблици, нещата стоят по друг начин.
Mod_security се справя добре спрямо SQLi атаки, въпреки малките пропуски. При другите анализи mod_security се дъни леко т.е. LFI, RFI. Рядкост е в наши дни да намериш RFI уязвимост, по-скоро е приложението да има само LFI уязвимост. Няма как да хване CSRF атаките, тъй като те са съвсем легитимни заявки. Но при правилно написан скрипт те могат да бъдат блокирани.
В крайна сметка изключително съм доволен от mod_security. Хваща повечето атаки, въпреки че ако някой идиот като мен тръгне да си играе с него, може да открие и още повече пропуски. Дори по забавното е, че ако хахор започне да търси топлата вода, може вече да бъде открита. Тоест искам да кажа, едно примерно търсене - bypass modsecurity - в някой хахорски форум , може да изкара доста резултати.
Дързайте!