Вероятно сте чували за HTTPS и как зеленият катинар в браузъра ви ни дава спокойствие. В света на разработването на приложения обаче сляпото доверие, че сертификатът е валиден, не винаги е достатъчно. Съществува скрит риск, при който, дори при криптирана връзка, някой може тайно да подслушва какво се случва между вашето устройство и сървъра.
За да се справи с тази уязвимост в сигурността, се появи техника, наречена „ Закрепване на сертификати “. По същество тя казва на нашето приложение: „Не се доверявайте на който и да е сертифициращ орган; приемайте връзката само ако сървърът представи точно този сертификат или публичен ключ.“ Това е все едно да поставим много строг пазач на вратата на нашата комуникация.
Какво точно е SSL Pinning и защо ни е необходимо?
За да разберем това правилно, първо трябва да помним, че стандартният HTTPS се основава на верига от доверие . Когато се свържете със сървър, той ви изпраща своя цифров сертификат. Вашето мобилно устройство проверява дали този документ е подписан от сертифициращ орган (CA), на който операционната система се доверява. Ако подписът е валиден и сертификатът не е изтекъл, връзката се установява.
Проблемът възниква, когато нападателят успее да проникне в средата на връзката, известната атака „Man-in-the-Middle“ (MITM) . Ако хакерът получи от сертифициращ орган (CA) издаване на измамен, но валиден сертификат, или ако успее да инсталира злонамерен root сертификат на устройството на жертвата, операционната система ще одобри връзката. В този момент нападателят може да прихване и промени чувствителни данни, като банкови данни или пароли, без потребителят да забележи нещо необичайно.
Тук се намесва pinning. Вместо да се доверява на който и да е разпознат CA, приложението съхранява копие на сертификата на сървъра или хеша на публичния ключ. По време на handshake приложението сравнява получения сертификат със съхранения. Ако не съвпадат бит по бит, връзката се прекратява незабавно, предотвратявайки подправянето на сървъра.
Видове закотвяне: Сертификати срещу публични ключове
Не всяко закрепване се извършва по един и същи начин. В зависимост от това какво решим да „закрепим“, имаме два основни подхода. Първият е Закрепване на сертификат , при което съхраняваме пълния файл на сертификата (.pem или .der). Това е най-лесният вариант за внедряване, но и най-досадният за поддръжка, тъй като всеки път, когато сертификатът на сървъра изтече и бъде подновен, ще трябва да актуализираме приложението в хранилището, или потребителите ще загубят услугата.
Втората опция е „Закрепване на публичен ключ“ . В този случай съхраняваме само хеша (обикновено SHA-256) на публичния ключ на сертификата. Основното предимство е, че публичният ключ може да остане непокътнат, дори ако сертификатът бъде подновен, което ни дава по-голяма гъвкавост на сертификата и намалява честотата на принудителните актуализации на приложенията. Освен това, като се съхранява само хеш, кодът е по-чист и по-труден за извличане от някой, който се опитва да го разработи чрез обратно инженерство.
Техническа имплементация на различни платформи
Ако работим с AndroidНай-модерният начин е да използвате файла network_security_config.xmlВ този XML файл дефинираме домейните и хешовете на сертификатите (пиновете), които искаме да оторизираме, което ни позволява да Активирайте основни настройки за сигурност на Android нативно. След това просто свързваме този файл в AndroidManifest.xmlВ миналото по-сложни неща се правеха чрез презаписване на класа. DefaultHttpClient и управление на хранилища за сертификати на Java чрез keytoolВъпреки това, XML-базираната конфигурация е много по-ефективна.
В екосистемата на IOSНещата се променят малко. Можем да се възползваме от App Transport Security (ATS), като конфигурираме файла Info.plist за дефиниране на закотвените домейни. За пълен контрол обаче е обичайно да се внедрява валидиране по време на изпълнение, използвайки URLSessionDelegateПри метода за проверка на удостоверяването, ние извличаме сертификата от сървъра и го сравняваме с локално съхранен сертификат в пакета с приложения.
За тези, които използват Кондензаторни или хибридни рамкиИма плъгини като @capgo/capacitor-ssl-pinning които унифицират процеса. В тези случаи конфигурацията обикновено се извършва в конфигурационния файл на приложението, като се посочва списъкът със сертификати и се активира валидирането. Жизненоважно е тези реализации да се тестват с инструменти като Чарлз Прокси, симулирайки MITM атака, за да потвърди, че приложението ефективно отхвърля връзката, когато сертификатът не е очакваният.
Рискове, ограничения и поддръжка
Финирането не е само слънце и рози. Най-голямата опасност е това, което се нарича блокиране поради изтичане . Ако сертификатът на сървъра изтече и не сте актуализирали приложението с новия ПИН код, всички ваши потребители ще видят грешки при свързване. За да избегнете това бедствие, най-добрата практика е да внедрите резервни ПИН кодове . Ние съхраняваме хеша на вторичен публичен ключ, който ще използваме само в случай на спешност или неочаквана ротация.
От друга страна, закачването може да бъде главоболие за разработчиците, които трябва да отстраняват грешки в комуникациите си. За да работят инструментите за наблюдение, понякога е необходимо да се деактивира закачването в среди за разработка или да се създадат специфични версии за отстраняване на грешки, като винаги се гарантира, че тази функционалност е активирана в производствената версия, която достига до крайния потребител.
Що се отнася до мрежата, Chrome беше пионер в прилагането на подобни концепции. Той използва HSTS (HTTP Strict Transport Security) , за да наложи използването на HTTPS и поддържа списък с „предварително заредени“ сайтове, за да предотврати уязвимостта при първи контакт. Въпреки че стандартът HPKP съществуваше за мрежата, той в крайна сметка беше престанал да се използва, защото беше твърде рискован и можеше да направи уебсайтовете недостъпни, ако възникне грешка в конфигурацията.
Внедряването на закрепване на сертификати е стратегическо решение, което балансира максималната сигурност с оперативността на услугата. Като ограничаваме доверието до конкретни обекти, ние защитаваме комуникацията от сложни атаки, при условие че поддържаме строг контрол върху жизнения цикъл на нашите ключове и сертификати, за да избегнем оставянето на клиентите без достъп.
