З початку 2022 року я витратив свій час на проведення аудитів безпеки та тестів на проникнення для додатків Laravel. Я перевіряв програми будь-якого розміру, від крихітних додатків з жменькою контролерів до величезних додатків з безліччю модулів і багатьма різними стилями кодування та структурами додатків.
Серед усього цього, існує досить чітка тенденція, яка справедлива для програм, які я перевірив: Laravel досить безпечний, але легко не помітити дрібниці, додаткові шари оборони та залишити слабкість, ховаючись десь.
Насправді, справедливо буде сказати, що переважна більшість проблем, які я виявив під час аудиту, були або чимось простим, що не було пропущено в одному маршруті, або додатковими рівнями безпеки, про які розробники або не знали, або не зручно впроваджувати.
Тож давайте зануримося в це та перевіримо 10 найпоширеніших проблем безпеки, які я виявив, проводячи аудит безпеки.
#10 → Недостатня перевірка вводу Часто зустрічається недостатня перевірка
введення, розкидана по контролерах. Часто буде валідатор, який перевіряє очікувані вхідні ключі (хоча іноді навіть цього немає), а потім request()->all() буде використовуватися відразу після цього, подаючи дані в моделі, події і т.д. Без належної перевірки легко вводити шкідливі значення, щоб викликати помилки, ін'єкційні атаки тощо.
Наприклад, звичайний захист від масових призначень для цього вважається $fillable на моделі, але якщо $fillable включає admin прапорець для адмін-порталу, то будь-хто може створити нового адмін-користувача зі сторінки реєстрації... (І так, це реальний приклад.)
#9 → Відсутня цілісність субресурсів (SRI)Цілісність субресурсів (SRI)
додає рівень захисту від скомпрометованих сценаріїв 3rd, що впливають на ваш сайт, і, на мою думку, серйозно недостатньо використовується. Ризик полягає в тому, що сценарії та стилі 3rd party можуть бути змінені, щоб включити шкідливий код, такий як Magecart, кейлоггери, криптомайнери тощо. Якщо на вашому сайті включено зламаний сценарій, користувачі ризикують, навіть якщо ваш додаток не зламано.
SRI працює шляхом визначення хешу цілісності на кожному <script> & <style> тезі, який завантажує сторонній ресурс 3rd, який браузер перевіряє перед завантаженням ресурсу. Якщо хеш не збігається, ресурс блокується.
Більшість сайтів, які я перевіряв, не завантажували ресурси від 3-х партій і, отже, все одно не потребували ІКД, інакше я очікував, що це буде набагато вище в списку!
#8 → Недостатнє обмеження швидкості Обмеження швидкості має важливе значення для обмеження
атак ботів та запобігання зловживанням, і все ж часто зустрічаються кінцеві точки, яким не вистачає обмеження швидкості. Це викликає особливе занепокоєння, коли мова йде про такі маршрути, як аутентифікація або запит конфіденційної інформації, як-от наявність облікових записів користувачів. Наприклад, я виявив, що маршрут багатофакторної автентифікації (MFA) на основі SMS не мав обмеження швидкості - і 6-значний код закінчився через 5 хвилин. Було банально перебрати дійсний код і силою пробитися всередину. 😈
Тим не менш, обмеження швидкості може бути складним для правильного визначення - ви базуєте його на IP, імені користувача чи обох? Або щось інше? Це залежить від маршруту, але мати деякі, безумовно, краще, ніж жодного. Тож не забувайте про це!
#7 → Міжсайтові сценарії (XSS)Один
з найбільш несподіваних записів у топ-10, але він, ймовірно, набагато нижчий, ніж ви очікували! XSS зазвичай з'являється на одному маршруті через один вхід, через щось на зразок Markdown (який небезпечний за замовчуванням) або обмежене форматування, яке постраждало від ледь помітного обходу втечі.
Найкраща стратегія тут полягає в тому, щоб звернути увагу на ці надокучливі теги лез ({!! … !!}) і необроблені директиви HTML, такі як v-html, і переконатися, що всі способи використання належним чином уникнені, що функції безпеки Markdown увімкнені, а HTML, наданий користувачем, очищений. Я рекомендую уникати цих тегів якомога більше, щоб будь-яке використання дійсно виділялося і могло бути легко ідентифіковано та переглянуто.
#6 → Застарілі та вразливі залежності Ще
один несподіваний запис... Саме тоді, коли ви востаннє запускали оновлення композитора / npm?
Зазвичай затримують оновлення залежностей, щоб уникнути порушення та підтримувати стабільність системи, але вразливості залежностей можуть залишити ваші програми відкритими, не роблячи нічого. Також часто включається безліч залежностей, але кожна залежність збільшує потенційні вразливості, про які потрібно знати.
Я рекомендую оновлювати все щотижня або щомісяця, а також використовувати такі інструменти, як composer audit --locked і npm audit у вашій системі збірки, щоб блокувати розгортання при виявленні вразливостей. Я також пропоную скоротити свої залежності до мінімуму, і все, що можна легко замінити простим внутрішнім проміжним програмним забезпеченням або обгорткою, має бути.
#5 → Використання небезпечної функції
Я втратив підрахунок кількості разів, які я бачив md5(time()) (і md5(microtime())!) використовував з тих пір, як почав працювати в PHP - я, мабуть, навіть написав кілька з них у свої ранні роки! І, на жаль, ця тенденція триває досі. Гірше того, він часто використовується для створення випадкових токенів або унікальних імен файлів. За винятком того, що він не випадковий і не унікальний. Це неймовірно легко вгадати і груба сила, і атаки зіткнень також можуть бути досить тривіальними.
Б'юся об заклад, якщо ви зараз зайдете у свою кодову базу і шукаєте md5(, ви знайдете десь її небезпечно ... Серйозно, у мене травма через це!
Це не тільки md5(time()) конкретно, але й інші функції, подібні rand() до тихarray_rand(), які не є криптографічно безпечними і не повинні довіряти всьому, що вимагає безпеки.
Завжди використовуйте належні безпечні генератори random_int() випадкових чисел і Str::random(), щоб безпечно генерувати випадкові значення.
#4 → Відсутні заголовки
безпеки Тепер ми переходимо до додаткових рівнів захисту, які недостатньо зрозумілі. Веб-браузери включають купу дійсно чудових функцій безпеки, вам просто потрібно ввімкнути їх на своєму сайті за допомогою заголовків відповідей. Хоча їх відсутність безпосередньо не відкриває ваш сайт для злому, вони допомагають запобігти таким речам, як клікджекінг, витік інформації про референтів, XSS та інші ін'єкційні атаки, атаки на пониження версії HTTPS тощо. Увімкнення багатьох із цих заголовків безпеки є тривіальним, але більшість сайтів навіть не вмикають прості... 😭
Найкраща пропозиція, яку я можу вам дати, - це перейти до securityheaders.com та просканувати свій сайт. У ньому буде перелічено всі відсутні заголовки та наведено посилання на ресурси, щоб дізнатися більше про їх додавання.
#3 → Відсутня політика безпеки вмісту (CSP)
Політика безпеки вмісту настільки важлива, що я дав їм власне місце в Топ-10. CSP є другорядною лінією захисту від XSS і клікджекінгу, і дають вам можливість бачити, які скрипти, стилі, шрифти, форми, фрейми тощо запускаються у вашому додатку. CSP повідомляє браузеру, які ресурси дозволено використовувати на сайті, і заблокує та/або повідомить про будь-які порушення політики - запобігаючи XSS-атакам і надаючи вам видимість того, що відбувається на вашому сайті.
Їх часто відкидають як занадто жорсткі або «зламані», однак розгортання політики лише для звітів забезпечує повну видимість, нічого не порушуючи. Тож це, безумовно, шлях, який потрібно йти, коли ви починаєте! Найпростіший спосіб налаштувати його – скористатися майстром CSP в Report URI.
Я опублікував своє проміжне програмне забезпечення CSP як простий спосіб розпочати роботу з CSP: https://gist.github.com/valorin/d4cb9daa190fdee90603efaa8cbc5886
#2 → Відсутня авторизація О, хлопче, цей містить купу речей, пов'язаних з авторизацією
(і певним чином аутентифікацією). Я бачив: незахищені прямі посилання на об'єкти (IDOR), відсутніsigned, аутентифікацію та проміжне програмне забезпечення політики, забуті authorize() дзвінки, веб-хуки без перевірки тощо... Зрештою, код насправді не перевіряв, чи дозволено запитувачу робити те, що він хоче робити.
Насправді я був здивований, побачивши це так високо в списку, але виявляється, що досить часто для більшості проектів один з них ховається десь, чекаючи, поки його експлуатують. Зазвичай це простий випадок, коли розробник забуває додати рядок, але це потенційно залишає величезну діру.
Моя найкраща рекомендація тут - включити тести для аутентифікації та авторизації на кожному маршруті, поряд з іншими вашими тестами. Таким чином, ви перевіряєте дійсні та недійсні дозволи як частину стандартного тестування, і помітите, якщо авторизація відсутня, оскільки тест пройде, коли він повинен бути невдалим.
#1 → Відкриті ключі та паролі
API Скільки разів я маю це сказати? Не вкладайте секрети в Git! 😡
Це був несподіваний чемпіон списку: ключі API і паролі були передані в контроль версій і розкидані по кодових базах. Це настільки смішно поширене явище, я, чесно кажучи, дивуюся, коли не стикаюся з цим під час аудиту.
Подумайте, куди йде ваш код... Він є на всіх ваших машинах розробників, спільно з підрядниками, на GitHub, Bitbucket, GitLab тощо в сервісах 3rd party та інструментах для створення. Він розкиданий по багатьох різних місцях. У той час як ваші ключі API розблоковують платежі, зберігання файлів, особисту інформацію, резервні копії, інфраструктуру тощо. Так багато конфіденційної інформації та доступу, і якщо вона потрапляє в чужі руки, ваша репутація зникає.
Я знаю, що існують навчальні посібники, які рекомендують здійснювати ці речі, тому я можу зрозуміти, чому це відбувається. Але це те, над чим нам потрібно наполегливо працювати, щоб зупинитися як спільнота.
Якщо ви випадково підтвердили облікові дані, переконайтеся, що ви відкликали їх у джерелі. Це завадить будь-кому використовувати його, якщо вони його знайдуть. Я також пропоную використовувати такі інструменти, як Gitleaks і TruffleHog, щоб знайти секрети у ваших кодових базах.
БОНУС → Відсутня безпека.txt файл!
Це не проблема безпеки як така, тому я включив її як бонус, але додавання security.txt файлу до вашого додатка є однією з найпростіших і найкращих речей, які ви можете зробити для своєї безпеки.
security.txt is a text file that you put at /.well-known/security.txt, which provides your (security) contact details in case someone finds a security issue with your site. This makes it super easy for security folks to contact you, reducing the time and effort it takes to report issues so you can get them fixed faster.
Створіть його тут: https://securitytxt.org
Резюме
Гаразд, друзі, це мій топ-10! Чи були якісь сюрпризи? Що потрібно перевірити у власних додатках? Можливо, було щось, з чим ви не згодні? Перейдіть до гілки у Twitter, Fediverse або Substack Notes, щоб приєднатися до обговорення!
Ключовий висновок для мене полягає в тому, що, хоча Laravel в безпеці, це всі дрібниці, які не помічаються і пропускаються. Легко припустити, що ви перевірили авторизацію на кожному маршруті, і ваш вихід повністю зник, але може бути один випадок, який ви пропустили. Це перевага аудиту безпеки - змусити когось, хто не робить припущень, переглянути ваш код. Це також те, що я викладаю на своєму курсі практичної безпеки Laravel.
