Ідеальна безпека сайту

22 Лютого 2010

Найпопулярніше питаня до мене це "Як зробити, щоб нічого не робити, а сайт був супер-безпечний", і постійно я відповідав по різному максимально приховуючи АБСОЛЮТНО-СУПЕР-СЕКРЕТНУ технологію, що була розроблема століння назад. І лише сьогодні цім секретом поділюся ), тож якщо ви хочете створювати безпечний сайт, то ось 5 рекомендацій:

  1. При програмуванні використовуйте фреймворки, типу ЗендФреймворка, КодеІгнайтера, Джанго, чи інших подібних. Використання фреймворків захищає вас від банальних помилок. Якщо говорити про Джанго, то в нім по замовчуванні є влаштований захист від майже всіх типів атак - SQL-inj, CSRF, XSS. Ці фреймворки написані великою кількістю розумних людей, тому помилок там дуже мало. Набагато менше, ніж якщо б ви цей функціонал писали самі.
  2. Закривайте все по IP.
  3. Закривайте все по IP.
  4. Закривайте все по IP, якщо в вас є адмінка на сайті, то вхід до неї також закривайте по IP. Це дуже просто і супер надійно. Звичайно трішки "неудобства" добавить вам в зв'язку з необхідністю використуванням VPN коли не з основного місця працюєте, але це того варте. Наприклад, якщо зловмисник навіть дізнається адмінський пароль, то він абсолютно нічого не зможе зробити. Це просто реалізується в усіх веб-серверах, а я юзаю nginx, і в нім в конфігі є такі рядки:
    location /admin/ { allow 127.0.0.1; deny all; ... }
  5. І знову - закривайте все по IP, якщо в вас є MySQL, FTP і все інше, то все це закривайте файрволом. На сервак повинен бути доступ з будь якого IP лише до ssh з сертифікатом і великим паролем.
Оце і всі ті основні правила, що ви повинні знати і їх використовувати. Якщо ви зробете як я кажу, і вас все одно зламають, то я буду винен вам пляшку пива! Чесне Слово Піонера! )
Коментарі Tags:  

Проблеми це життя

17 Вересня 2009

Цікаво, чи подобаються вам проблеми? Що для вас краще - жити з проблемами, чи без них?

Бо я вже давно для себе визначився що життя без проблем неможливе... Це ж було б надзвичайно скучно. Ось тільки подумайте, що ви сама багатша людина, та й всі люди вас обожнюють, тай маєте все що побажаєте. Ну можливо це цікаво буде день, чи два... Але не більше. Ні до чого йти. Немає цілі. Мені краще життя з проблемами, чим без них. Лише від проблем можливо отримати задоволення, а точніше ти борешся з проблемою, а потім коли все вирішується - ти на сьомому небі. І чим складніша була проблема, тим більше насолоди отримаємо від її вирішення. Нехай можливо інколи здається, що з проблеми немає виходу, але це так лише здається, і це є ознака того що скоро проблема здасться.

І ось лише декілька хвилин назад я вирішив проблему, що не піддавалась годин з 5. П'ять безперервних годин я бився над її вирішенням, і навіть не знав, чи зможу її вирішити, але все ж таки вона піддалася. Задача була наступна - є такий код:

location = /1 { fastcgi_param SCRIPT_FILENAME /usr/www/index.php; error_page 403 404 405 406 407 408 409 410 411 412 413 414 500 501 502 503 504 505 506 507 509 510 = @fallback; } location @fallback { proxy_pass http://some; proxy_intercept_errors on; error_page 403 404 405 406 407 408 409 410 411 412 413 414 500 501 502 503 504 505 506 507 509 510 = /error.html; } location /error.html { root /usr/www/error; }

Це налаштування сервера nginx, яке спочатку повинно отримати запит і обробити його ПХП скриптом, якщо виникне помилка, то запит потрібно направити на якийсь інший бек-енд, якщо і там буде помилка, то потрібно показати статичну сторінку з помилкою. І як я не пробував, але nginx ніяк не хотів направляти помилку на статичну сторінку... Тож бився я над цим, міняв конфіги, тестив, і знову щось міняв, а результату не було. Але через години праці на очі попався один параметр, що включає рекурсивність в помилках, тобто вложеність повинна б спрацювати... Вніс в конфіг строчку: recursive_error_pages on;

І все, нарешті запрацювало! Уряяяя! ;)

Тож, я хочу сказати, якщо вже руки опускаються перед проблемою, то зроби ще крок, бо може до результату лише один крок залишився. А потім ще один, і ще один... І не вчуєшся коли будеш на вершині.

Коментарі Tags:  

Django. Отладка, несколько мелочей

31 Липня 2009

При відладці Django і запуску влаштованого сервера - він часто видає забагато інформації, наприклад про запити до медіа файлів. А це ж нас мало цікавить, тому давайте розглянемо частину веб-сервера влаштованого, що розміщується в файлі django/core/servers/basehttp.py:

def log_message(self, format, *args): # Don't bother logging requests for admin images or the favicon. if self.path.startswith(self.admin_media_prefix) or self.path == '/favicon.ico': return sys.stderr.write("[%s] %s\n" % (self.log_date_time_string(), format % args))

Де в коментах пишиться, що не буде показувати адмінські картинки і фавікон, тож можем цей кусок модифікувати так:

def log_message(self, format, *args): # Don't bother logging requests for admin images or the favicon. if self.path.startswith(self.admin_media_prefix) or self.path == '/favicon.ico': return if self.path.startswith('/media/') or self.path.startswith('/__debug__/'): return sys.stderr.write("[%s] %s\n" % (self.log_date_time_string(), format % args))

Лише одна маленька умова, яка не універсальна і досить не красива, але ж скільки користі там!

PS: щось я взагалі помішався на Пітоні і Джанго, але ж це добре )

Коментарі Tags:  
 
 
 
Роман Хоменко aka PresidentUA
mail/jabber: spirt40@gmail.com