Задаволены
- 01. Падтрымлівайце праграмнае забеспячэнне ў актуальным стане
- 02. Сачыце за ўвядзеннем SQL
- 03. Абараніце ад XSS-нападаў
- 04. Сцеражыцеся паведамленняў пра памылкі
- 05. Праверце з абодвух бакоў
- 06. Праверце свае паролі
- 07. Пазбягайце загрузкі файлаў
- 08. Карыстайцеся HTTPS
- 09. Атрымаць інструменты бяспекі вэб-сайта
Магчыма, вы не думаеце, што на вашым сайце ёсць што-небудзь вартае ўзлому, але сайты ўвесь час скампраметаваны. Большасць парушэнняў бяспекі вэб-сайтаў заключаецца не ў крадзяжы вашых даных і непрыманні макета вэб-сайта, а ў спробе выкарыстаць ваш сервер у якасці рэтрансляцыі электроннай пошты для спаму альбо ў наладжванні часовага вэб-сервера, як правіла, для абслугоўвання файлаў незаконнага характару . Іншыя вельмі распаўсюджаныя спосабы злоўжывання кампраметаванымі машынамі ўключаюць выкарыстанне вашых сервераў як часткі бот-сеткі альбо майнинг біткойнаў. На вас могуць патрапіць нават вымагальнікі.
Узлом рэгулярна праводзіцца з дапамогай аўтаматызаваных сцэнарыяў, напісаных для пошуку ў Інтэрнэце, каб паспрабаваць выкарыстаць вядомыя праблемы бяспекі вэб-сайтаў у праграмным забеспячэнні. Вось нашы дзевяць лепшых саветаў, якія дапамогуць вам і вашаму сайту бяспечна ў Інтэрнэце.
01. Падтрымлівайце праграмнае забеспячэнне ў актуальным стане
Гэта можа здацца відавочным, але забеспячэнне актуальнасці ўсяго праграмнага забеспячэння вельмі важна для забеспячэння бяспекі вашага сайта. Гэта датычыцца як аперацыйнай сістэмы сервера, так і любога праграмнага забеспячэння, якое вы можаце запусціць на сваім вэб-сайце, напрыклад, CMS або форуму. Калі ў праграмным забеспячэнні выяўляюцца дзіркі ў бяспецы вэб-сайтаў, хакеры хутка спрабуюць злоўжываць імі.
Калі вы выкарыстоўваеце рашэнне для кіраванага хостынгу, вам не трэба так турбавацца аб ужыванні абнаўленняў бяспекі для аперацыйнай сістэмы, бо хостынг-кампанія павінна паклапаціцца пра гэта.
Калі вы карыстаецеся на сваім вэб-сайце праграмнае забеспячэнне іншых вытворцаў, напрыклад, CMS або форум, вам трэба пераканацца, што вы хутка ўжываеце любыя патчы бяспекі. У большасці пастаўшчыкоў ёсць спіс рассылання альбо RSS-канал, у якім падрабязна паведамляецца пра любыя праблемы бяспекі вэб-сайта. WordPress, Umbraco і многія іншыя CMS паведамляюць пра наяўныя абнаўленні сістэмы пры ўваходзе ў сістэму.
Многія распрацоўшчыкі выкарыстоўваюць такія інструменты, як Composer, npm або RubyGems, для кіравання залежнасцямі праграмнага забеспячэння, а ўразлівасці сістэмы бяспекі, якія ўзнікаюць у пакеце, ад якога вы залежыце, але не звяртаючы на гэта ўвагі, - адзін з самых простых спосабаў вылавіць. Пераканайцеся, што вы падтрымліваеце свае залежнасці ў актуальным стане, і выкарыстоўвайце такія інструменты, як Gemnasium, каб атрымліваць аўтаматычныя апавяшчэнні, калі ў адным з вашых кампанентаў аб'яўлена ўразлівасць.
02. Сачыце за ўвядзеннем SQL
Атакі ўвядзення SQL - гэта выпадкі, калі зламыснік выкарыстоўвае поле вэб-формы альбо параметр URL для атрымання доступу да вашай базы дадзеных і маніпулявання ёю. Калі вы выкарыстоўваеце стандартны Transact SQL, лёгка несвядома ўставіць у ваш запыт код ізгояў, які можна выкарыстоўваць для змены табліц, атрымання інфармацыі і выдалення дадзеных. Вы можаце лёгка прадухіліць гэта, заўсёды выкарыстоўваючы параметрызаваныя запыты, большасць вэб-моў мае гэтую функцыю, і яе лёгка рэалізаваць.
Разгледзім гэты запыт:
"SELECT * FROM table WHERE column =’ "+ параметр +" ’;"
Калі зламыснік змяніў параметр URL на "або" 1 '=' 1, гэта прывядзе да таго, што запыт будзе выглядаць так:
"SELECT * FROM table WHERE слупок =’ ’АБО’ 1 ’=’ 1 ’;"
Паколькі «1» роўна «1», гэта дазволіць зламысніку дадаць дадатковы запыт у канец заявы SQL, які таксама будзе выкананы.
Вы можаце выправіць гэты запыт, відавочна параметрызуючы яго. Напрыклад, калі вы выкарыстоўваеце MySQLi ў PHP, гэта павінна стаць:
$ stmt = $ pdo-> падрыхтаваць (’SELECT * АД табліцы WHERE слупок =: значэнне’); $ stmt-> выканаць (масіў (’значэнне’ => параметр $));
03. Абараніце ад XSS-нападаў
Міжсайтавыя сцэнарыі (XSS) атакуюць шкоднасны JavaScript на вашых старонках, які затым запускаецца ў аглядальніках вашых карыстальнікаў і можа змяніць змест старонкі альбо скрасці інфармацыю, каб адправіць яе зламысніку. Напрыклад, калі вы паказваеце каментарыі на старонцы без праверкі, зламыснік можа адправіць каментарыі, якія змяшчаюць тэгі сцэнарыяў і JavaScript, якія могуць працаваць у аглядальніку любога іншага карыстальніка і выкрасці іх печыва для ўваходу, што дазваляе атацы ўзяць пад кантроль уліковы запіс кожнага карыстальнік, які прагледзеў каментарый. Вам трэба пераканацца, што карыстальнікі не могуць уводзіць актыўны змест JavaScript на вашы старонкі.
Гэта выклікае асаблівую занепакоенасць у сучасных вэб-прыкладаннях, дзе старонкі цяпер ствараюцца ў асноўным з карыстацкага кантэнту і якія ў многіх выпадках ствараюць HTML, які потым таксама інтэрпрэтуецца такімі інтэрфейснымі платформамі, як Angular і Ember. Гэтыя фрэймворкі забяспечваюць мноства XSS-абаронак, але змешванне рэндэрынгу сервера і кліента стварае новыя і больш складаныя магчымасці атакі: не толькі эфектыўна ўводзіць JavaScript у HTML, але і ўводзіць змест, які будзе запускаць код, устаўляючы дырэктывы Angular альбо выкарыстоўваючы Ember памочнікі.
Галоўнае тут - засяродзіцца на тым, як ваш змест, які ствараецца карыстальнікам, можа выйсці за межы, якіх вы чакаеце, і быць інтэрпрэтаваны браўзэрам як нешта іншае, чым тое, што вы хацелі. Гэта падобна на абарону ад ін'екцыі SQL. Пры дынамічнай генерацыі HTML выкарыстоўвайце функцыі, якія відавочна ўносяць змены, якія вы шукаеце (напрыклад, выкарыстоўвайце element.setAttribute і element.textContent, якія браўзэр аўтаматычна пазбягае, а не ўсталёўваць element.innerHTML ад рукі), альбо выкарыстоўвайце функцыі у вашым інструменце шаблонаў, які аўтаматычна робіць адпаведны экранінг, а не аб'ядноўвае радкі альбо ўсталёўвае сыры змест HTML.
Яшчэ адным магутным інструментам у наборы інструментаў абаронцы XSS з'яўляецца Палітыка бяспекі змесціва (CSP). CSP - гэта загаловак, які можа вярнуць ваш сервер, які кажа аглядальніку абмежаваць, як і які JavaScript выконваецца на старонцы, напрыклад, забараніць працу любых сцэнарыяў, не размешчаных у вашым дамене, забараніць убудаваны JavaScript альбо адключыць eval (). У Mozilla ёсць цудоўны гід з некалькімі прыкладамі канфігурацый. Гэта абцяжарвае працу сцэнарыяў зламысніка, нават калі яны могуць патрапіць на вашу старонку.
04. Сцеражыцеся паведамленняў пра памылкі
Будзьце асцярожныя, колькі інфармацыі вы перадаяце ў паведамленнях пра памылкі. Пакажыце карыстальнікам толькі мінімальныя памылкі, каб яны не выдавалі сакрэты, якія прысутнічаюць на вашым серверы (напрыклад, ключы API або паролі баз дадзеных). Не паведамляйце і поўную інфармацыю аб выключэннях, бо гэта можа значна палегчыць складаныя атакі, такія як ін'екцыя SQL. Захоўвайце падрабязныя памылкі ў часопісах сервера і паказвайце карыстальнікам толькі неабходную інфармацыю.
05. Праверце з абодвух бакоў
Праверка заўсёды павінна праводзіцца як з боку аглядальніка, так і з боку сервера. Аглядальнік можа выяўляць простыя збоі, такія як абавязковыя палі, якія з'яўляюцца пустымі, і калі вы ўводзіце тэкст у поле толькі з лічбамі. Аднак іх можна абыйсці, і вы павінны пераканацца, што правяраеце наяўнасць праверкі і больш глыбокай праверкі на баку сервера, бо, калі гэтага не зрабіць, у базу дадзеных можа быць устаўлены шкоднасны код альбо код сцэнарыя, альбо гэта можа прывесці да непажаданых вынікаў на вашым сайце.
06. Праверце свае паролі
Усе ведаюць, што павінны выкарыстоўваць складаныя паролі, але гэта не азначае, што яны робяць гэта заўсёды. Вельмі важна выкарыстоўваць надзейныя паролі для адміністратара сервера і вэб-сайта, але не менш важна таксама настойваць на належнай практыцы выкарыстання пароляў для карыстальнікаў, каб абараніць бяспеку сваіх уліковых запісаў.
Як бы гэта не спадабалася карыстальнікам, захаванне патрабаванняў да пароля, такіх як мінімум каля васьмі знакаў, уключаючы вялікую літару і лічбу, дапаможа абараніць іх інфармацыю ў доўгатэрміновай перспектыве.
Паролі заўсёды павінны захоўвацца ў выглядзе зашыфраваных значэнняў, пераважна з выкарыстаннем аднабаковага алгарытму хэшавання, такога як SHA. Выкарыстанне гэтага метаду азначае, што пры праверцы сапраўднасці карыстальнікаў вы параўноўваеце толькі зашыфраваныя значэнні. Для дадатковай бяспекі вэб-сайта пажадана пасаліць паролі, выкарыстоўваючы новую соль для кожнага пароля.
У выпадку ўзлому і крадзяжу вашых пароляў выкарыстанне хэшаваных пароляў можа дапамагчы абмежаваць шкоду, бо іх расшыфраваць немагчыма. Лепшае, што хто-небудзь можа зрабіць, гэта атака па слоўніку альбо атака грубай сілай, па сутнасці адгадваючы кожную камбінацыю, пакуль не знойдзе супадзення. Пры выкарыстанні салёных пароляў працэс узлому вялікай колькасці пароляў яшчэ больш павольны, бо кожнае здагадка павінна быць хэшавана асобна для кожнай солі + пароля, што ў вылічальных закладах вельмі дарагое.
На шчасце, многія CMS забяспечваюць кіраванне карыстальнікамі адразу з вялікай колькасцю гэтых убудаваных функцый бяспекі вэб-сайтаў, хоць некаторыя канфігурацыі або дадатковыя модулі могуць спатрэбіцца для выкарыстання салёных пароляў (да Drupal 7) альбо для ўстанаўлення мінімальнай надзейнасці пароля. Калі вы выкарыстоўваеце .NET, тады варта выкарыстоўваць пастаўшчыкоў членства, бо яны вельмі наладжвальныя, забяспечваюць убудаваную бяспеку вэб-сайтаў і ўключаюць гатовыя элементы кіравання для скіду ўваходу і пароля.
07. Пазбягайце загрузкі файлаў
Дазвол карыстальнікам загружаць файлы на ваш сайт можа стаць вялікай рызыкай для бяспекі, нават калі гэта проста змена аватары. Рызыка заключаецца ў тым, што любы загружаны файл, якім бы нявінным ён ні выглядаў, можа ўтрымліваць скрыпт, які пры выкананні на вашым серверы цалкам адкрывае ваш сайт.
Калі ў вас ёсць форма для загрузкі файлаў, вам трэба ставіцца да ўсіх файлаў з вялікай падазронасцю. Калі вы дазваляеце карыстальнікам загружаць выявы, вы не можаце спадзявацца на пашырэнне файла альбо тып mime, каб пераканацца, што файл з'яўляецца выявай, бо іх лёгка можна падрабіць. Нават адкрыццё файла і чытанне загалоўка альбо выкарыстанне функцый для праверкі памеру выявы не з'яўляюцца бяспраўнымі. Большасць фарматаў малюнкаў дазваляюць захоўваць раздзел каментарыяў, які можа ўтрымліваць PHP-код, які можа быць выкананы серверам.
Дык што вы можаце зрабіць, каб гэтага не дапусціць? У рэшце рэшт вы хочаце спыніць карыстальнікам магчымасць выканаць любы файл, які яны загружаюць. Па змаўчанні вэб-серверы не будуць спрабаваць выконваць файлы з пашырэннямі малюнкаў, але не спадзявайцеся выключна на праверку пашырэння файла, бо, як вядома, праходзіць файл з імем image.webp.php.
Некаторыя варыянты: перайменаваць файл пры загрузцы, каб забяспечыць правільнае пашырэнне файла, альбо змяніць дазвол файла, напрыклад, chmod 0666, каб яго не ўдалося выканаць. Пры выкарыстанні * nix вы можаце стварыць файл .htaccess (гл. Ніжэй), які дазволіць доступ толькі да ўсталяваных файлаў, якія прадухіляюць згаданую раней атаку двайнога пашырэння.
забараніць з усіх файлаў ~ "^ w + . (gif | jpe? g | png) $"> загад забараніць, дазволіць дазволіць з усіх / Файлы>
У рэшце рэшт, рэкамендаванае рашэнне - увогуле прадухіліць прамы доступ да загружаных файлаў. Такім чынам, любыя файлы, загружаныя на ваш сайт, захоўваюцца ў тэчцы за межамі webroot альбо ў базе дадзеных у выглядзе BLOB. Калі вашы файлы непасрэдна даступныя, вам трэба будзе стварыць сцэнар для атрымання файлаў з прыватнай тэчкі (альбо апрацоўшчыка HTTP у .NET) і даставіць іх у браўзэр. Тэгі малюнкаў падтрымліваюць атрыбут src, які не з'яўляецца прамым URL-адрасам выявы, таму атрыбут src можа паказваць на сцэнар дастаўкі файлаў, забяспечваючы правільны тып змесціва ў загалоўку HTTP. Напрыклад:
img src = "/ imageDelivery.php? id = 1234" />? php // imageDelivery.php // Дастаць імя файла выявы з базы дадзеных на аснове $ _GET ["id"] ... // Даставіць малюнак у загаловак аглядальніка (' Змест зместу: выява / gif '); файл прачытання (’images /’.$ fileName); ?> var13 ->
Большасць хостынг-правайдэраў займаецца канфігурацыяй сервера для вас, але калі вы размяшчаеце свой вэб-сайт на сваім уласным серверы, вам трэба будзе праверыць некалькі рэчаў.
Пераканайцеся, што ў вас усталяваны брандмаўэр, і вы блакуеце ўсе неабавязковыя парты. Па магчымасці наладжванне DMZ (дэмілітарызаванай зоны), якая дазваляе доступ толькі да знешняга свету да партоў 80 і 443. Хоць гэта можа быць немагчыма, калі ў вас няма доступу да вашага сервера з унутранай сеткі, бо вам спатрэбіцца адкрыць парты, каб дазволіць загрузку файлаў і выдалены ўваход на ваш сервер праз SSH альбо RDP.
Калі вы дазваляеце загружаць файлы з Інтэрнэту, выкарыстоўвайце толькі бяспечныя спосабы транспартавання на ваш сервер, такія як SFTP або SSH.
Па магчымасці запусціце базу дадзеных на серверы, які адрозніваецца ад сервера. Гэта азначае, што да сервера баз дадзеных немагчыма атрымаць непасрэдны доступ з вонкавага свету, толькі ваш вэб-сервер можа атрымаць да яго доступ, мінімізуючы рызыку траплення вашых дадзеных.
Нарэшце, не забудзьцеся пра абмежаванне фізічнага доступу да вашага сервера.
08. Карыстайцеся HTTPS
HTTPS - гэта пратакол, які выкарыстоўваецца для забеспячэння бяспекі праз Інтэрнэт. HTTPS гарантуе, што карыстальнікі размаўляюць з серверам, якога яны чакаюць, і што ніхто іншы не можа перахапіць альбо змяніць змесціва, якое яны бачаць падчас транзіту.
Калі ў вас ёсць што-небудзь, што вашым карыстальнікам можа спатрэбіцца прыватнае, настойліва рэкамендуецца выкарыстоўваць толькі HTTPS для яго дастаўкі. Гэта, вядома, азначае старонкі крэдытнай карты і ўваходу (і URL-адрасы, на якія яны падаюць), але звычайна значна большую частку вашага сайта. Форма ўваходу часта ўсталёўвае файл cookie, напрыклад, які адпраўляецца разам з кожным другім запытам на ваш сайт, які робіць карыстальнік, які ўвайшоў у сістэму, і выкарыстоўваецца для аўтэнтыфікацыі гэтых запытаў. Зламыснік, які скраў гэта, зможа выдатна імітаваць карыстальніка і пераняць яго сеанс ўваходу. Каб перамагчы падобныя атакі, вы амаль заўсёды хочаце выкарыстоўваць HTTPS для ўсяго свайго сайта.
Гэта ўжо не так складана і дорага, як было. Давайце шыфраваць прадастаўляюць абсалютна бясплатныя і аўтаматызаваныя сертыфікаты, якія вам спатрэбяцца для ўключэння HTTPS, а таксама існуюць існуючыя інструменты супольнасці для шырокага спектру распаўсюджаных платформаў і фрэймворкаў, якія аўтаматычна наладжваюць гэта для вас.
Характэрна, што Google абвясціў, што павялічыць вас у рэйтынгу пошуку, калі вы выкарыстоўваеце HTTPS, даючы гэта таксама перавагу для SEO. Небяспечны HTTP ужо на выхадзе, і цяпер час абнавіць яго.
Ужо паўсюдна выкарыстоўваеце HTTPS? Ідзіце далей і паглядзіце наладжванне HTTP Strict Transport Security (HSTS), простага загалоўка, які вы можаце дадаць да адказаў сервера, каб забараніць небяспечны HTTP для ўсяго вашага дамена.
09. Атрымаць інструменты бяспекі вэб-сайта
Пасля таго, як вы падумаеце, што зрабілі ўсё магчымае, прыйшоў час праверыць бяспеку вашага сайта. Найбольш эфектыўны спосаб зрабіць гэта пры дапамозе некаторых інструментаў бяспекі вэб-сайтаў, якія часта называюць тэставаннем на пранікненне альбо скарочаным тэсціраваннем.
Ёсць шмат камерцыйных і бясплатных прадуктаў, якія дапамогуць вам у гэтым. Яны працуюць аналагічна хакерам сцэнарыяў: яны правяраюць усе вядомыя эксплоіты і спрабуюць скампраметаваць ваш сайт, выкарыстоўваючы некаторыя з папярэдніх згаданых метадаў, такіх як SQL Injection.
Некалькі бясплатных інструментаў, на якія варта паглядзець:
- Netsparker (даступна бясплатная версія супольнасці і пробная версія). Добра для тэставання SQL-ін'екцый і XSS
- OpenVAS сцвярджае, што з'яўляецца самым перадавым сканерам бяспекі з адкрытым зыходным кодам. Добра для тэставання вядомых уразлівасцяў, у цяперашні час скануе больш за 25 000. Але гэта можа быць складана наладзіць і патрабуе ўсталёўкі сервера OpenVAS, які працуе толькі на * nix. OpenVAS - гэта відэлец Nessus, перш чым ён стаў камерцыйным прадуктам з закрытым зыходным кодам.
- SecurityHeaders.io (бясплатная праверка ў Інтэрнэце). Інструмент для хуткага паведамлення, якія згаданыя вышэй загалоўкі бяспекі (напрыклад, CSP і HSTS) уключылі і правільна сканфігуравалі дамен.
- Xenotix XSS Exploit Framework Інструмент ад OWASP (Адкрыты праект бяспекі вэб-прыкладанняў), які ўключае ў сябе велізарны выбар прыкладаў атак XSS, якія вы можаце запусціць, каб хутка пацвердзіць, ці ўразлівыя дадзеныя вашага сайта ў Chrome, Firefox і IE.
Вынікі аўтаматызаваных тэстаў могуць ашаламіць, бо прадстаўляюць мноства патэнцыйных праблем.Галоўнае, каб у першую чаргу засяродзіцца на найважнейшых пытаннях. Кожнае паведамленне, як правіла, мае добрае тлумачэнне патэнцыйнай уразлівасці. Верагодна, вы выявіце, што некаторыя праблемы сярэдняга / нізкага ўзроўню не хвалююць ваш сайт.
Ёсць некалькі крокаў, якія вы можаце зрабіць, каб паспрабаваць скампраметаваць ваш сайт уручную, змяніўшы значэнні POST / GET. Тут вам можа дапамагчы праксі-сервер для адладкі, які дазваляе перахопліваць значэнні HTTP-запыту паміж вашым браўзэрам і серверам. Папулярная бясплатная праграма пад назвай Fiddler з'яўляецца добрай адпраўной кропкай.
Такім чынам, што вы павінны паспрабаваць змяніць на запыт? Калі ў вас ёсць старонкі, якія павінны быць бачныя толькі карыстальніку, які ўвайшоў у сістэму, паспрабуйце змяніць параметры URL, такія як ідэнтыфікатар карыстальніка альбо значэнні файлаў cookie, каб паспрабаваць праглядзець падрабязнасці іншага карыстальніка. Іншая вобласць, якую варта праверыць, - гэта формы, змена значэнняў POST для спробы адпраўкі кода для выканання XSS альбо загрузка сцэнарыя на баку сервера.
