Вам потрібно визначити найкращий час для зачаття, запобігти небажаній вагітності або ж дізнатися, коли секс із вашим партнером буде найкращим? Раніше для цього жінкам доводилося вирушати на консультацію до свого лікаря, проте тепер у них з'явився новий найкращий друг – смартфон.
В останні роки з'явилося багато додатків для жінок, які дозволяють з легкістю відстежувати фертильні дні і час настання овуляції, а також робити особисті позначки. Крім цього, вони мають багато інших функцій. Одним з таких програм є Glow, яким користуються вже 47 мільйонів жінок. Glow дозволяє відстежувати такі речі, як настрій жінок, а також якість та частоту сексу. Завдяки цьому додатку з'явилася можливість отримати ці цікаві факти про інтимне життя жінок з усього світу.
Найкращі країни для жінок
1. Вам не вистачає інтиму? Вирушайте до Канади. Виявляється, канадки займаються сексом на 45% частіше, ніж середні користувачі програми.
2. Але будьте обережні: Канада – відмінне місце, щоб завагітніти. Канадські жінки можуть завагітніти на 21% легше, ніж решта.
3. Австралійки також часто займаються сексом – на 37% більше, ніж користувачі програми у середньому.
4. Чи варто говорити, що жінки в Австралії також мають добрі шанси завагітніти? Вони на 14% вище, ніж в інших користувачів.
5. США – гарне місце, щоб стати щасливою. Американки на 16% частіше за інших жінок займаються сексом.
6. Найгірше місце, щоб стати щасливою? Латинська Америка. Тут жінки займаються сексом на 4% рідше, ніж середньостатистичні користувачі програми.
Сексуальні апетити
1. Сексуальний апетит жінки відповідає її місячному циклу. Першим днем циклу вважається перший день менструації, що триває приблизно п'ять днів. Таким чином, жінки найменше цікавляться сексом від одного до п'яти днів на місяць.
2. Багато жінок повідомляють про зміну рівня енергії або настрою в цей час, і це пов'язано, зазвичай, зі зниженням сексуального потягу. Також жінки менш зацікавлені у сексі ще цілий тиждень після менструації.
3. Більшість жінок знову починають займатися сексом на 12-й день циклу.
4. Багато жінок мають регулярні сексуальні стосунки з 12 по 14 день циклу. Програма Glow називає ці дні «піком сексуальності».
5. Насправді жінки почуваються найбільш сексуальними на 13 та 14 день свого циклу. Але ось що цікаво: вони не обов'язково в цей час отримують найкращий секс, що задовольняє.
6. Найбільше жінки насолоджуються сексом в останній 30-й день свого циклу. Цей день у Glow позначений як «пік оргазмів».
Чи задоволені жінки
1. Жінки почуваються найбільш щасливими у 15-й та 16-й дні свого циклу, а також у тому випадку, коли у них було багато сексу у попередні дні.
2. Користувачі Glow за два роки зареєстрували 7,6 млн. сексуальних контактів.
3. Це означає, що кожну хвилину принаймні сім жінок, які використовують Glow, займаються сексом.
4. До речі, користувачі також повідомили про свою закоханість 2 мільйони разів. Також додаток відстежує цикли сексу та фертильність 88 тисяч пар.
5. На жаль, попри наявні сексуальні контакти, в повному обсязі жінки ними задоволені. Майже третина жінок готова швидше відмовитись від сексу, ніж від смартфона.
6. Але це все одно означає, що дві третини швидше за все відмовляться від телефонів, ніж від сексу.
Вітання. Мене звуть Сашко Баранник. У Mail.Ru Group я керую відділом веб-розробки, що складається із 15 співробітників. Ми навчилися створювати сайти для десятків мільйонів користувачів та спокійно впораємося з кількома мільйонами денної аудиторії. Сам я займаюся веб-розробкою близько 20 років, і останні 15 років роботи програмувати доводиться переважно на PHP. Хоча можливості мови та підхід до розробки за цей час сильно змінилися, розуміння основних уразливостей та вміння від них захиститися залишаються ключовими навичками будь-якого розробника.
В інтернеті можна знайти багато статей та посібників з безпеки. Ця книга здалася мені досить докладною, при цьому лаконічною та зрозумілою. Сподіваюся, вона допоможе вам дізнатися щось нове та зробити свої сайти надійнішими та безпечнішими.
PS Книга довга, тому переклад викладатиметься кількома статтями. Отже, почнемо…
Ще одна книга з безпеки в PHP?
Є багато способів, щоб почати книгу про безпеку в PHP. На жаль, я не читав жодної з них, тому доведеться розібратися з цим у процесі написання. Мабуть, я почну з самого основного і сподіватимусь, що все вийде.Якщо розглянути абстрактну веб-програму, запущену в онлайні компанією Х, то можна припустити, що вона містить ряд компонентів, які, якщо їх зламати, здатні завдати істотної шкоди. Який, наприклад?
- Шкода користувачам:отримання доступу до електронної пошти, паролів, персональних даних, реквізитів банківських карток, ділових таємниць, списків контактів, історії транзакцій і секретів, що глибоко охороняються (на кшталт того, що хтось назвав свого собаку Блесткой). Витік цих даних шкодить користувачам (приватним особам та компаніям). Нашкодити можуть також веб-застосунки, що неправильно застосовують подібні дані, і вузли, які використовують довіру користувачів у своїх інтересах.
- Шкода самої компанії X:через заподіяні користувачам збитки погіршується репутація, доводиться виплачувати компенсації, втрачається важлива ділова інформація, виникають додаткові витрати - на інфраструктуру, поліпшення безпеки, ліквідацію наслідків, судові витрати, великі допомоги топ-менеджерам, що звільняються, і т.д.
На жаль, питання безпеки дуже часто вирішуються заднім числом. Вважається, що найважливіше - створити додаток, що відповідає потребам користувачів, з прийнятним бюджетом і терміном. Це цілком зрозумілий набір пріоритетів, але не можна завжди ігнорувати безпеку. Набагато краще постійно пам'ятати, впроваджуючи конкретні рішення під час розробки, коли вартість змін ще невелика.
Вторинність безпеки – багато в чому результат культури програмування. Одні програмісти покриваються холодним потом при думці про вразливість, інші можуть заперечувати наявність вразливості до того часу, поки зможуть довести, що це взагалі вразливість. Між цими двома крайнощами є багато програмістів, які просто знизають плечима, тому що у них поки що не йшло все навперейми. Їм важко зрозуміти цей дивний світ.
Оскільки система безпеки веб-програми повинна захищати користувачів, які довіряють сервісам програми, необхідно знати відповіді на запитання:
- Хто хоче нас атакувати?
- Як вони можуть нас атакувати?
- Як ми можемо зупинити їх?
Хто хоче нас атакувати?
Відповідь на перше запитання дуже проста: все і все. Так, весь Всесвіт хоче вас провчити. Пацан з розігнаним комп'ютером, на якому запущений Kali Linux? Мабуть, він вас атакував. Чоловік, який любить вставляти палиці в колеса? Мабуть, він уже найняв когось, щоб вас атакували. Довірений REST API, через який ви щогодини отримуєте дані? Ймовірно, він був хакнутий ще місяць тому, щоб підкидати вам заражені дані. Навіть я можу вас атакувати! Тож не треба сліпо вірити цій книзі. Вважайте, що я брешу. І знайдіть програміста, який виведе мене на чисту воду та викриє мої шкідливі поради. З іншого боку, можливо, він теж збирається вас хакнути.Сенс цієї параної в тому, щоб було простіше розділити на категорії все, що взаємодіє з вашим веб-додатком («Користувач», «Хакер», «База даних», «Ненадійне введення», «Менеджер», «REST API») , а потім присвоювати кожній категорії індекс довіри. Очевидно, що Хакеру довіряти не можна, але що щодо Бази даних? «Ненадійне введення» отримало свою назву не просто так, але ви дійсно станете фільтрувати пост у блозі, отриманий з довіреної Atom-стрічки свого колеги?
Ті, хто серйозно займаються зломом веб-застосунків, вчаться використовувати перевагу такого мислення, частіше атакуючи не вразливі джерела даних, а довірені, які з меншою ймовірністю матимуть хорошу систему захисту. Це не випадкове рішення: у реальному житті суб'єкти з вищим індексом довіри викликають менше підозри. Саме на такі джерела даних я насамперед звертаю увагу під час аналізу програми.
Повернемося до «Баз даних». Якщо припустити, що хакер зможе отримати доступ до бази (а ми, параноїки завжди це припускаємо), то їй ніколи не можна довіряти. Більшість додатків довіряють базам без будь-яких питань. Зовні веб-додаток виглядає єдиним цілим, але всередині воно являє собою систему окремих компонентів, що обмінюються даними. Якщо рахувати всі ці компоненти довіреними, то при зломі одного з них швидко виявляться скомпрометовані і всі інші. Такі катастрофічні проблеми в безпеці не вдасться вирішити фразою: «Якщо база зламана, то ми все одно програли». Ви можете сказати, але зовсім не факт, що вам доведеться це робити, якщо спочатку не довірятимете базі і діяти відповідно!
Як вони можуть нас атакувати?
Відповідь на друге питання – досить великий список. Ви можете бути атаковані звідусіль, звідки отримує дані кожен компонент або шар веб-програми. По суті, веб-програми просто обробляють дані і перекладають їх з місця на місце. Користувацькі запити, бази даних, API, стрічки блогів, форми, куки, репозиторії, змінні PHP-середовища, конфігураційні файли, знову конфігураційні файли, навіть виконувані вами PHP-файли - всі вони можуть бути потенційно заражені даними для прориву системи безпеки . По суті, якщо шкідливі дані не присутні явно в PHP-коді, що використовується для запиту, то, ймовірно, вони прийдуть в якості «корисного навантаження». Передбачається, що: а) ви написали вихідний PHP-код; б) він був правильно відрецензований, і в) вам не заплатили представники кримінальних організацій.Якщо ви використовуєте джерела даних без перевірки того, чи безпечні ці дані і чи підходять вони для використання, то ви потенційно відкриті для атаки. Також необхідно перевіряти, що отримані дані відповідають даним, які ви надсилаєте. Якщо дані не зроблені повністю безпечними для виведення, то у вас також будуть серйозні проблеми. Все це можна виразити як правила для PHP «Перевіряйте введення; екрануйте висновок».
Це очевидні джерела даних, які ми маємо якось контролювати. Також до джерел можуть належати сховища за клієнта. Наприклад, більшість програм розпізнають користувачів, присвоюючи їм унікальні ID сесії, які можуть зберігатися в куках. Якщо атакуючий набуде значення з куки, він може видати себе іншого користувача. І хоча ми можемо зменшити деякі ризики, пов'язані з перехопленням або підробкою даних, гарантувати фізичну безпеку комп'ютера користувача ми не в змозі. Ми навіть не можемо гарантувати, що користувачі визнають «123456» безглуздим паролем після «password». Додаткову пікантність надає факт, що сьогодні печінка не єдиний вид сховища на стороні користувача.
Ще один ризик, що часто не береться до уваги, стосується цілісності вашого вихідного коду. У PHP стає все популярнішим розробка додатків на основі великої кількості слабо пов'язаних один з одним бібліотек, модулів та пакетів для фреймворків. Багато хто з них завантажується з громадських репозиторіїв, таких як Github, ставляться за допомогою установників пакетів типу Composer і його веб-компаньйону Packagist.org. Тому безпека вихідного коду залежить від безпеки всіх цих сторонніх сервісів і компонентів. Якщо виявиться скомпрометований Github, то, швидше за все, він буде використаний для роздачі коду зі шкідливою добавкою. Якщо Packagist.org - атакуючий зможе перенаправляти запити пакетів на свої, шкідливі пакети.
На сьогоднішній день Composer і Packagist.org схильні до відомих вразливостей у визначенні залежностей і роздачі пакетів, тому завжди перевіряйте всі двічі в робочому оточенні і звіряйте джерело отримання всіх пакетів з Packagist.org.
Як ми можемо зупинити їх?
Прорив системи безпеки веб-програми може бути завданням як простим до безглуздості, так і вкрай витратним за часом. Справедливо припустити, що у кожному веб-додатку десь є вразливість. Причина проста: всі програми роблять люди, а людям властиво помилятися. Так що ідеальна безпека – це нездійсненна мрія. Всі програми можуть містити вразливість, і завдання програмістів - мінімізувати ризики.Вам доведеться добре подумати, щоб знизити ймовірність збитків від атаки на веб-додаток. По ходу розповіді я розповідатиму про можливі способи атак. Одні їх очевидні, інші немає. Але в будь-якому випадку для вирішення проблеми необхідно брати до уваги деякі основні принципи безпеки.
Базові принципи безпеки
Під час створення засобів захисту їх ефективність можна оцінювати з допомогою таких міркувань. Деякі я вже наводив вище.- Не вірте нікому та нічому.
- Завжди припускайте найгірший сценарій.
- Застосовуйте багаторівневий захист (Defence-in-Depth).
- Дотримуйтесь принципу "чим простіше, тим краще" (Keep It Simple Stupid, KISS).
- Дотримуйтесь принципу "мінімальних привілеїв".
- Зловмисники відчувають неясність.
- Читайте документацію (RTFM), але їй ніколи не довіряйте.
- Якщо це не тестували, це не працює.
- Це завжди ваша помилка!
1. Не вірте нікому та нічому
Як уже говорилося вище, правильна позиція - припускати, що все і все, з чим взаємодіє ваш веб-додаток, хочуть його зламати. У тому числі інші компоненти або шари програм, які потрібні для обробки запитів. Все та все. Без виключень.2. Завжди передбачайте найгірший сценарій
Багато систем безпеки мають спільну властивість: не важливо, наскільки добре вони зроблені, кожна може бути пробита. Якщо ви це враховуватимете, то швидко зрозумієте перевагу другого пункту. Орієнтування на найгірший сценарій допоможе оцінити широкість та ступінь шкідливості атаки. А якщо вона справді відбудеться, то, можливо, вам вдасться зменшити неприємні наслідки завдяки додатковим засобам захисту та змінам в архітектурі. Можливо, традиційне рішення, яке ви використовуєте, вже замінили на щось найкраще?3. Застосовуйте багаторівневий захист (Defence-in-Depth)
Багаторівневий захист запозичений з військової науки, тому що люди давно зрозуміли, що численні стіни, мішки з піском, техніка, бронежилети та фляжки, що прикривають життєво важливі органи від ворожих куль та мечів, - правильний підхід до безпеки. Ніколи не знаєш, що з перерахованого не захистить, і потрібно зробити так, щоб кілька рівнів захисту дозволяли покладатися не лише на польове зміцнення або бойовий порядок. Звісно, річ не лише в одиночних відмових. Уявіть собі нападника, який заліз на гігантську середньовічну стіну сходами і виявив, що за нею ще одна стіна, звідки його обсипають стрілами. Хакери будуть почуватися так само.4. Дотримуйтесь принципу "чим простіше, тим краще" (Keep It Simple Stupid, KISS)
Найкращі засоби захисту завжди прості. Їх просто розробляти, впроваджувати, розуміти, використовувати та тестувати. Простота зменшує кількість помилок, стимулює правильну роботу програми та полегшує впровадження навіть у найбільш складних та недружніх оточеннях.5. Дотримуйтесь принципу «мінімальних привілеїв»
Кожен учасник обміну інформацією (користувач, процес, програма) повинен мати ті права доступу, які необхідні для виконання своїх функцій.6. Зловмисники відчувають неясність
«Безпека через неясність» заснована на припущенні, що якщо ви використовуєте захист А і нікому не кажете, що це, як вона працює і чи існує взагалі, це чарівним чином допомагає вам, тому що атакуючі опиняються в розгубленості. Насправді, це дає лише невелику перевагу. Найчастіше досвідчений зловмисник здатний обчислити вжиті вами заходи, тому потрібно використовувати явні засоби захисту. Тих, хто зайве впевнений у тому, що неясний захист скасовує необхідність у захисті реального, потрібно спеціально карати заради позбавлення від ілюзій.7. Читайте документацію (RTFM), але ніколи їй не довіряйте
Посібник з PHP - це Біблія. Звичайно, воно не було написане Літаючим Макаронним Монстром, так що формально може містити якусь кількість напівправди, недоліків, неправильних тлумачень чи помилок, поки що не помічених чи не виправлених. Те саме стосується і Stack Overflow.Спеціалізовані джерела мудрості у сфері безпеки (орієнтовані на PHP і не тільки) загалом дають докладніші знання. Найближче до Біблії з безпеки в PHP знаходиться сайт OWASP з пропонованими на ньому статтями, посібниками та порадами. Якщо на OWASP щось не рекомендується робити – ніколи не робіть!
8. Якщо це не тестували, це не працює
Впроваджуючи засоби захисту, ви повинні писати всі необхідні для перевірки тести, що працюють. У тому числі вдаєте, що ви хакер, за яким плаче в'язниця. Це може здатися надуманим, але знайомство з методами злому веб-додатків – гарна практика; ви дізнаєтеся про можливі вразливості, а ваша параноя посилиться. При цьому необов'язково розповідати посібнику про нову подяку за злом веб-додатку. Для виявлення вразливостей обов'язково використовуйте автоматизовані інструменти. Вони корисні, але звичайно ж не замінюють якісне реву коду і навіть ручне тестування програми. Чим більше ресурсів ви витратите на тестування, тим надійнішим буде ваш додаток.9. Це завжди ваша помилка!
Програмісти звикли вважати, що вразливості в системі безпеки будуть знаходитись розрізненими атаками, а їхні наслідки незначні.Наприклад, витоки даних (добре задокументований і широко розповсюджений вид злому) часто розглядаються як невеликі проблеми у безпеці, тому що вони не впливають на користувачів безпосередньо. Однак витік даних про версії ПЗ, мови розробки, розташування вихідного коду, про логіку програми та бізнес-логіку, про структуру бази даних та інші аспекти оточення веб-додатка та внутрішніх операцій часто важливий для успішної атаки.
У той самий час атаки на системи безпеки часто є комбінації атак. Окремо вони незначні, але при цьому іноді відкривають дорогу іншим атакам. Наприклад, для впровадження SQL-коду іноді потрібне ім'я конкретного користувача, яке можна отримати за допомогою атаки за часом (Timing Attack) проти адміністративного інтерфейсу, замість більш дорогого і помітного брутфорсу. У свою чергу, впровадження SQL дозволяє реалізувати XSS-атаку на конкретний адміністративний обліковий запис, не привертаючи уваги великою кількістю підозрілих записів у логах.
Небезпека ізольованого розгляду вразливостей - у недооцінці їхньої загрози, а отже, і в надто безтурботному ставленні до них. Програмісти нерідко лінуються виправляти вразливість, бо вважають її надто незначною. Також практикується перекладання відповідальності за безпечну розробку на кінцевих програмістів або користувачів, причому часто без документування конкретних проблем: навіть існування цих вразливостей не визнається.
Незначність, що здається, не важлива. Безвідповідально змушувати програмістів або користувачів виправляти ваші вразливості, особливо якщо ви навіть не поінформували про них.
Перевірка вхідних даних
Перевірка вхідних даних - це зовнішній периметр вашого веб-додатку. Він захищає основну бізнес-логіку, обробку даних та генерацію вихідних даних. У буквальному значенні все поза цього периметра, крім коду, виконуваного поточним запитом, вважається ворожою територією. Всі можливі входи та виходи периметра день і ніч охороняються войовничими вартовими, які спочатку стріляють, а потім ставлять запитання. До периметру підключені «союзники», що окремо охороняються (і дуже підозріло виглядають), включаючи «Модель», «Базу даних» і «Файлову систему». Ніхто в них стріляти не хоче, але якщо вони спробують випробувати долю… бах. Кожен союзник має свій власний периметр, який може довіряти чи не довіряти нашому.Пам'ятаєте мої слова, кому можна довіряти? Нікому й нічого. У світі PHP скрізь зустрічається рада не довіряти «введеним користувачем даним». Це одна з категорій за рівнем довіри. Припускаючи, що користувачам довіряти не можна, ми вважаємо, що решті довіряти можна. Це не так. Користувачі – найбільш очевидне ненадійне джерело вхідних даних, тому що ми їх не знаємо і не можемо ними керувати.
Критерії перевірки
Перевірка вхідних даних - це і найочевидніший, і найненадійніший захист веб-програми. Переважна більшість вразливостей відбувається через збої системи перевірки, тому дуже важливо, щоб ця частина захисту працювала правильно. Вона може підвести, але все одно дотримуйтеся таких міркувань. Завжди враховуйте при реалізації кастомних валідаторів та використанні сторонніх бібліотек для валідації, що сторонні рішення зазвичай виконують загальні завдання та опускають ключові процедури перевірки, які можуть знадобитися саме вашому додатку. При використанні будь-яких бібліотек, призначених для потреб безпеки, обов'язково самостійно перевіряйте їх на вразливість та коректність роботи. Також рекомендую не забувати, що PHP може демонструвати дивну і, можливо, небезпечну поведінку. Подивіться цей приклад, взятий з функцій фільтрації:Filter_var("php://example.org", FILTER_VALIDATE_URL);
Фільтр проходить без запитань. Проблема в тому, що прийнятий URL php:// може бути переданий PHP-функції, яка очікує на отримання віддаленої HTTP-адреси, а не повернення даних від виконуваного PHP-скрипта (через PHP-обробник). Вразливість виникає оскільки опція фільтрації немає методу, обмежує допустимі URI. Незважаючи на те, що програма очікує посилання http, https або mailto, а не якийсь URI, характерний для PHP. Потрібно всіма способами уникати подібного, надто загального підходу до перевірки.
Будьте обережні з контекстом
Перевірка вхідних даних повинна запобігати введенню у веб-програму небезпечних даних. Серйозний камінь спотикання: перевірка на безпеку даних зазвичай виконується лише першого передбачуваного використання.Допустимо, я отримав дані, що містять ім'я. Я досить просто можу перевірити його на наявність апострофів, дефісів, дужок, прогалин та цілого ряду алфавітно-цифрових Unicode-символів. Ім'я - це коректні дані, які можуть бути використані для відображення (перше передбачуване використання). Але якщо використовувати його десь ще (наприклад, у запиті до бази даних), то воно опиниться в новому контексті. І деякі символи, які допустимі в імені, в цьому контексті виявляться небезпечними: якщо ім'я перетворюється на рядок для виконання SQL-ін'єкції.
Виходить, що перевірка вхідних даних насправді ненадійна. Вона найефективніша для відсікання однозначно неприпустимих значень. Скажімо, коли щось має бути цілим числом, або буквено-цифровим рядком, або URL-HTTP. Такі формати та значення мають свої обмеження і при належній перевірці з меншою ймовірністю становитимуть загрозу. Інші значення (необмежений текст, GET/POST-масиви та HTML) перевіряти важче, і можливість отримання шкідливих даних у них вище.
Оскільки більшу частину часу наша програма передаватиме дані між контекстами, ми не можемо просто перевірити всі вхідні дані і вважати справу завершеною. Перевірка на вході – лише перший контур захисту, але в жодному разі не єдиний.
Поряд із перевіркою вхідних даних дуже часто використовується такий метод захисту, як екранування. З його допомогою дані перевіряються на безпеку під час входу до кожного нового контексту. Зазвичай цей метод застосовують для захисту від міжсайтового скриптингу (XSS), але він затребуваний і в багатьох інших завданнях як засіб фільтрації.
Екранування захищає від помилкового тлумачення отримувачем вихідних даних. Але цього недостатньо - у міру надходження даних у новий контекст потрібна перевірка спеціально для конкретного контексту.
Хоча це може сприйматися як дублювання валідації при початковому введенні, насправді додаткові стадії перевірки краще враховують особливості поточного контексту, коли вимоги до даних дуже відрізняються. Наприклад, дані, що надходять з форми, можуть містити відсоткове число. При першому використанні ми перевіряємо, що значення дійсно ціле. Але при передачі в модель нашої програми можуть виникнути нові вимоги: значення має вкладатися у певний діапазон, обов'язковий для роботи бізнес-логіки програми. І якщо у новому контексті не виконуватиметься ця додаткова перевірка, то можуть виникнути серйозні проблеми.
Використовуйте лише білі списки, а не чорні
Чорні та білі списки – це два первинні підходи до перевірки вхідних даних. Чорні мають на увазі перевірку на неприпустимі дані, а білі - на припустимі. Білі списки краще, тому що при перевірці передаються тільки ті дані, які ми очікуємо. У свою чергу, чорні списки враховують лише припущення програмістів про всі можливі хибні дані, тому тут набагато легше заплутатися, щось пропустити або помилитися.Хороший приклад - будь-яка процедура перевірки, покликана зробити HTML безпечним з погляду неекранованих вихідних даних шаблоні. Якщо використовувати чорний список, то нам потрібно перевірити, щоб HTML не містив небезпечних елементів, атрибутів, стилів та JavaScript. Це великий обсяг роботи, і засоби очищення HTML, що базуються на чорних списках, завжди примудряються не помічати небезпечні комбінації коду. А засоби, що використовують білі списки, усувають цю невизначеність, допускаючи лише відомі дозволені елементи та атрибути. Всі інші будуть просто відокремлюватися, ізолюватися або видалятися незалежно від того, чим вони є.
Так що білі списки краще для будь-яких процедур перевірки завдяки вищій безпеці та надійності.
Ніколи не намагайтеся виправляти вхідні дані
Перевірка вхідних даних часто супроводжується фільтруванням. Якщо під час перевірки ми просто оцінюємо коректність даних (з видачею позитивного чи негативного результату), то фільтрація змінює дані, що перевіряються, щоб вони задовольняли конкретним правилам.Зазвичай це дещо шкодить. До традиційних фільтрів відносяться, наприклад, видалення з телефонних номерів всіх символів, за винятком цифр (у тому числі зайвих дужок та дефісів), або обрізання непотрібного горизонтального або вертикального простору. У подібних ситуаціях виконується мінімальне чищення, щоб виключити помилки під час відображення або передачі. Однак можна занадто захопитися використанням фільтрації для блокування шкідливих даних.
Один із наслідків спроби виправити вхідні дані: атакуючий може передбачити вплив ваших виправлень. Припустимо, є якесь неприпустиме рядкове значення. Ви його шукаєте, видаляєте та завершуєте фільтрацію. А якщо зловмисник створить значення, розділене рядком, щоб перехитрити ваш фільтр?
В этом примере простая фильтрация по тэгу ничего не даст: удаление явного тэга
