Книгата се опитва да опише всички основни концепции, които е нужно да разбираме до поне някаква степен, за да се подсигурим, до колкото е възможно (тъй като се твърди, че абсолютната безопасност е близка до невъзможното), че личните данни ще останат лични, че ще избегнем излишно изразходване на ресурси и че не злоупотребяваме с хората/машините които ползват нашите услуги. Oбхващат се много важни и интересни теми като валидиране на потребителски данни, SQL инжекции, Cross-Site скриптинг, Remote execution, кражба на сесия и обезопасяване на мрежови връзки (SSL, SSH), които смятам, че са задължителни знания за всеки програмист, който работи с уеб приложения.

Типове уязвимости:

• Когато се взема информация от потребители
  • Човешки атаки
    • Злоупотреба със съхранение
    • Използването на нашето приложение, за да се вреди на други хора или организации
    • Всяко приложение, което позволява потребителско гласуване или обратна връзка е уязвимо за Sock Puppet атаки
    • Griefers, Trolls and Pranksters
  • Автоматизирани атаки
    • Червеи и вируси (при които единствената разлика е, че вирусът трябва да е прикрепен към файл)
    • Спам
    • Автоматизирани потребителски входни данни
• Когато се дава информация на потребители
  • Harvesting e-mail addresses
  • Flooding e-mail addresses
  • Screen scraping
  • Improper archiving
• Други
  • Denial of service атаки
  • DNS атаки

Навици за максимална сигурност:

• Нищо не е подсигурено на 100%, трябва просто винаги да се покриват възможно най-много бази
• Никога не вярвай на потребителските входни данни
• Винаги предпочитай повече наслоени защити пред една много здрава защита
• По-простото приложение се защитава много по-лесно
• Peer review

II. Валидация и верификация на потребителски входни данни

– Вход на данни в невалиден формат може да счупи приложението, да запише грешни данни в базата или дори да ги изтрие, може да задейства уязвимости в други библиотеки или приложения, с които работи нашето приложение или просто да предизвика неочакван резултат.

Пазете се от:

• Поле, съдържащо мета-символи
• Прекалено големи по обем входни данни
• Злоупотреба със скрити елементи
• Входни данни, съдържащи непредвидени команди

Стратегии за валидиране на входни данни:

• Изключване на глобалните променливи
• Деклариране на променливи
• Позволяване единствено на очаквани входни данни
• Подсигуряване на типа, дължината и формата на входните данни
• Валидиране на стойности подавани към други системи
  • Мета-символи
    • Escape by prepending with “\”
    • Поставяне на кавички
    • Шифроване
  • Файлови пътища, имена и URI-та
    • стрингове, съдържащи имена на файлове са ограничени от файловата система по различни начини от другите стрингове
  • Емайл адреси
  • HTTP header стойности
    • Всякакви входни данни в Location: пренасочване, трябва да се шифроват с urlencode()
  • Заявки към бази
    • Escaping
  • HTML output
    • Използвай htmlentities() или htmlspecialchars() за PHP стойности в страниците
  • Shell аргументи
    • Потребителите никога не трябва да виждат PHP грешки

III. Предотвратяване на SQL инжекция

– Mогат да се използват външни решения като PearDB

Типове входни данни:

• Текстово поле във форма
• URI стойност

Стратегии:

• Използване на intval() за целочислени входни данни или подобна функция за числа
• Escape-ване на всички входни данни които не са числа

IV. Предотвратяване на Cross-Site Scripting

Видове:

• Външен сайт към сайта на приложението
  • Извиква се отвън или от емайл, или от друг сайт.
  • Потребителят е залъган да кликне на линк, да зареди картинка, или да submit-не форма.
• От сайта на приложението до външен сайт или до себе си
  • Извиква се локално, възползвайки се от доверието на потребителите в приложението.
  • Нападателят закрепя товар към коментар или друг стринг, който запазва входните данни в приложението.

Техники:

• HTML & CSS Mark-up атаки
  • Вкарването на HTML & CSS съдържание в HTML-а, чрез закрепване към коментар или някоя друга анотация, която се post-ва в сайта на приложението.
• JS атаки
  • Блог от JavaScript скрипт вкаран в HMLT-a на страницата.
• Фалшифицирани action URI-та
  • Ако приложението позволява важни действия да работят само по GET, то е уязвимо
• Фалшифицирани image source URI-та
  • Използва фалшифицирана картинка или source атрибута на елемента. За да залъже потребителя да изпълни някакво действие в приложението, без неговото намерение
• Допълнителен товар на форма
• Други
  • Възникват от употребата на Java аплети, actionscript филми и игри или разширения за браузър

Стратегии:

• Ефективното предотвратяване започва в началото, когато се замисля интерфейса, не в последните стадии
• Използване поток на работа да постави лимити, за всяка дадена страница, над това колко заявки са очаквани да последват, и да се отхвърлят заявки, които не идват от правилно място или пропускат важни потвърдителни стъпки
• Валидиране на всички потребителски изпратени URL-ли използвайки parse_url()
• Шифроване на HTML обекти, в полета, в които не се очаква HTML съдържание
• Изолиране на чувствителна активност в отделни API-та
• Предвиждане на действията на потребителя

V. Предотвратяване на външно изпълнение (Remote Execution)

– Приложения уязвими за този тип атаки са тези, които позволяват потребителски изпратени стойности да минат през eval(), или се инжектират в една от петте PHP изпълнителни функции, exec(), passthru(), proc_open(), shell_exec() and system()

Стратегии:

• Ограничаване на позволените файлови разширения (Unix файловете нямат нужда от разширения)
• Съхраняване на качванията отвън the web root (за да не може нападателят да изпълнява скриптове по URI)
• Валидиране на eval(), exec(), passthru(), proc_open(), shell_exec() и system() стойности
• Избягване на употребата на PHP скриптове от външни сървъри (или поне с използването им с hardcode-нато IP)
• Използвай Soap, XML или RPC заявки

VI. Налагане на сигурност върху краткотрайните файлове

Стратегии:

• Направи местоположението трудно
• Използване на tempnam() или fopen()
• Дефиниране на директорията на краткотрайните файлове в константа, например: define(‘TMP_DIR’, ‘/tmp’)
• Ограничаване на правата
• Записване само върху познати файлове (използване на checksums за проверка)
• Проверка на качени файлове (използване на is_uploaded_file())

VII. Кражба на сесия

Методи за придобиване на сесийно ID:

• Мрежово подслушване
• Unwitting exposure (когато PHP позволява сесийно ID от $_GET)
• Препращане, проксита и фишинг
• Фиксация

Стратегии:

• употреба на SSL
• употреба на cookies вместо $_GET
• употреба на сесиен таймаут
• регенериране на сесийното ID
• възползване от абстракцията в кода
• избягване на неефективни решения

VIII. REST (REpresentational State Transfer) услуги

Стратегии:

• употреба на SSL
• лимитиране на достъп до ресурси и формати
• Authenticating / authorising requests
• Enforcing quotas and rate limits

IX. Използване на CAPTCHAs

– Използват се, за да предотврати роботи от влизане в приложението
– В главата се обясняват в детайли видовете CAPTCHA, има дори примери как да си създадем собствен CAPTCHA, но поради факта, че има безброй готови и безплатни решения не смятам, че би се наложило на някой

X. User authentication, authorisation and logging

– В главата се обясняват в детайли видовете автентикационни системи, системи за контрол на достъпа, и логин системи, с които един програмист може да се увери, че приложенията се използват от правилните потребители по правилния начин

XI. Предотвратяване на загуби на данни

– Шифроването на важна информация в backup-ите е изключително важно
– Backup-ите не пазят всяка версия на файла, само версията, която е съществувала във времето на записване
– Само системните администратори могат да намират и възстановяват данни от backup
– Често да се възстановят малко файлове е трудно колкото да се възстанови цялата система

Техники:

• Заключване на записите (Record locking) и добре измислена форма за потвърждение за да се избегнат случайни грешки
• Избягване на изтриване на данни
• Versioning software

XII. Безопасно изпълняване на системни и външни процедурни извиквания

– В тази глава се обяснява в детайли, как да изолираме изпълнението на опасни системни команди или Remote procedure calls (RPCs)
– Изключително опасно е да се изпълняват PHP скриптове (изпълнени чрез анонимен потребител), които изпълняват sudo команди или suid библиотеки, защото тогава може да се злоупотреби с всяка уязвимост, за да се превземе целият сървър, sudo командата и други често се изтриват за лайф средата.

XIII. Обезопасяване на Unix

– Където се обяснява в детайли как да се обезопаси Unix система и докато би било нужно за всеки системен администратор да ги знае тези работи, не мисля, че би се наложило на програмист да се занимава с тях.

XIV. Обезопасяване на базата

Стратегии:

• Никога не стартирай сървъра като root, стартирай го като обикновен непревелигирован потребител
• Опазването на файловете с опции е изключително важно
• Директорията на базата трябва да е достъпна само за сървърния акаунт
• Преглеждай акаунтите на базата за опасни настройки или прекалени привилегии
• Контролиране на достъпа до базата с grant таблици
• Следвай consistent процес при създаване на нови акаунти на базата
• Редовни backup-и

XV. Шифроване и хеширане

– Шифроването се използва да се предават съобщения, които трябва да се пазят в тайна, докато са в движение, а хеширането се използва за да се потвърди, че полученото съобщение е същото като изпратеното.

Шифроване

• Симетрично
  • Двете страни споделят същия таен ключ
  • Подобни алгоритми са AES, Blowfish, и 3DES
• Асиметрично
  • Всяка страна разполага със собствено изграден чифт ключове и алгоритъм които подсигурява, че съобщението шифровано с даден ключ (публичен), може да се разшифрова само с друг даден ключ (частен)
  • Частните ключове често имат passphrase за допълнителна защита
  • Отнема се повече изчислителна сила и е по-сложно да се имплементира
  • Подобни алгоритми са RSA и Diffie-Hellman

Хеширане

• Теоретично е възможно две различни стойности да имат еднакви хеширани стойности
• Подобни алгоритми са MD5 и SHA-256

Кодиране

• Трансформира данните по схема, която е необходима за тяхното декодиране (обикновено публично разпространена)
• Подобен алгоритъм е base64

XVI. Oбезопасяване на мрежови връзки

– SSL (Secure Sockets Layer) и неговият наследник TLS (Transport Layer Security) са известни с ролите си в обезопасяването на HTTP комуникации. Използвайки сървър, който работи с HTTPS (HyperText Transport Protocol Secure) и правилно подписан сертификат, сайта може да гарантира, че данните, които се трансферират между сървър и клиент са шифровани, не са променяни докато пристигат, и че клиентската сесия не може да се “открадне”

SSL протоколи:

• Record протокол
  • Отговорен за записване и шифроване на всяко съобщение, вграждайки шифрованото съобщение в серии от TCP/IP пакети, сглобявайки съобщението от другия край и тогава вече го разшифрова и потвърждава
  • При начално свързване се задейства Handshake протокола
• Handshake протокол
  • Използван, за да се договори точният метод, по който ще се извърши размяната на ключовете, шифърът които ще се използва за шифроването на следващи съобщения и тип на кода за автентикация на съобщението, който ще се използва за потвърждение на съдържанието на съобщението
  • Методът за размяна на ключовете може да е Diffie-Hellman, който не изисква сертификат, също така може да е RCA както се използва в OpenSSL среда, който изисква сертификат

SSH (Secure SHell)

• За разлика от SSL, се използва за да се обезопасят връзки поради административни причини, като например безопасно копиране на файлове
• Праща или към command line или от външен хост към клиентски прозорец, по начин, по който може да се взаимодейства с външния хост, все едно си там физически. It’s client suite typically includes support for command line shell, file transfer, and window forwarding capability
• Не изисква конкретен алгоритъм за шифроване и се препоръчва използването на добре-установени алгоритми с key length 128 бита или повече
• Изисква клиент за да се използва и най-известният е OpenSSH

XVII. Последни препоръки

• Има прекалено много проблеми свързани с хостинга (due to scrapability of web server user id)
  • Read access to source code and supporting files
  • Access to system upload and temporary directories
  • Denial of service by CPU hogging
  • Transfer of security vulnerabilities
• Поддържането на отделни среди за разработка и продукция
• Постоянно обновяване на средите за да подсигуряване, за да сме сигурни, че имаме последните security patches.