Jak pracovat s credentials, jak dělat code review a další

Víte, jak ukládat aplikační credentials, a jak s nimi bezpečně pracovat? Co je to Vault a jak ho využít pro správu credentials? Děláte code review správně a efektivně? Stahněte si code review checklis

🏆 Téma: Práce s credentials a jejich ukládání

• Mezi credentials patří: hesla, tokeny nebo API klíče ke službám třetích stran, private klíče, service accounty a další secrets, které aplikace potřebuje ke svému fungování.

• Časté zásadní problémy práce s aplikačními credentials jsou třeba:

  • ukládání credentials v prostém textu do ENV souborů nebo přímo do kódu,

  • k secrets / credentials mají přístup všichni vývojáři.

Ukládání credentials

• Credentials nesmí být uloženy spolu s kódem aplikace.

• Pokud jsou credentials uloženy spolu s kódem aplikace, nikdy by neměly být uloženy v prostém textu, ale musí být vhodně zabezpečené - šifrované nebo hashované.

• Vývojáři často vytvářejí například .env soubory pro každé vývojové prostředí (development, produkce, staging, atp.), kde jsou credentials ukládány.

• Tyto soubory jsou často verzovány a credentials se dostávají na GitHub, GitLab a další platformy.

• To vede nejen k úniku dat, ale následkem může být také neoprávněné využívání služeb.

• Credentials je možné bezpečně ukládat například na GitHubu v sekci Repository secrets, AWS secrets manageru nebo HashiCorp Vaultu.

• Mezi časté problémy patří také zapisování přihlašovacích údajů od různých typů účtů do komentářů k určitým funkcionalitám.

• K předcházení úniku takového typu dat je možné použít nástroje typu gitleaks, které skenují zdrojový kód a celý repozitář, zda se v něm nevyskytují credentials, a pokud ano, vývojář je na to upozorněn.

• Credentials je možné ukládat jako součást kódu, ale musí být vhodně zabezpečené - šifrované nebo hashované, aby nedošlo k jejich úniku.

  • Tato varianta se i přesto nedoporučuje.

Správa credentials

• Credentials by měly být uloženy na bezpečném místě tak, aby k nim neměl přístup nikdo bez oprávnění.

• Pokud jsou credentials uloženy jako součást kódu, má k nim přístup každý, kdo má přístup ke zdrojovému kódu, což je v případě malých / středně velkých firem prakticky každý, kdo je součástí například GitHub organizace.

• V takovém případě je zvýšené riziko úniku credentials.

• Nástroje typu HashiCorp Vault umožňují ukládání credentials a řízení přístupu k nim.

• Credentials jsou uloženy šifrovaně a narozdíl od GitHub secrets je možné zobrazit si originální hodnotu credentials.

• Vývojáři totiž v mnoha případech potřebují testovat funkcionality např. staging prostředí a bez přístupu ke staging credentials by to nebylo možné.

• Tyto nástroje je možné zapojit do pipelines, které kód nasazují, a tím dojde k bezpečnému nastavení credentials pro danou aplikaci.

• Díky tomu je možné automatizovat proces správy credentials a omezit přístup k nim pouze na osoby, které ho potřebují.

• O nástroje se starají admini nebo DevOps oddělení ve spolupráci se security týmem (záleží na velikosti organizace a týmu).

  • V některých případech jde o jediné osoby, které mají plný přístup ke všem credentials.

• Jelikož jsou credentials velmi citlivé údaje, je potřeba v případě odchodu vývojáře, DevOps, admina a dalších členů týmu všechny credentials a přístupuvé údaje změnit.

  • To je ve firmách často zanedbáváno, protože proces je mnohdy velmi těžké automatizovat.

Jak na práci s credentials

• Neukládejte credentials v prostém textu jako součást kódu.

• Šifrujte nebo hashujte credentials, pokud je potřeba, aby byly součástí kódu.

• Využijte GitHub secrets, AWS secrets manager, Vault a další nástroje, které umožní správu credentials, jejich integraci do procesu nasazení aplikace a řízení přístupu.

• Neposílejte si credentials přes e-mail, Slack nebo jiné kanály.

  • Využijte Vault, případně password manager pro sdílení credentials mezi týmy a jejich členy.

• Omezte přístup ke credentials na osoby, které ho nutně potřebují na úrovni prostředí, např.:

  • development prostředí - přístup má celý tým, který na projektu pracuje,

  • staging prostředí - přístup mají vybraní pracovníci,

  • produkční prostředí - přístup nemá nikdo, případně jen lead vývojář.

• Použijte a integrujte nástroje typu gitleaks, jako např. pre-commit hook, ve svých pipelines, abyste odhalili použití credentials v kódu.

• Nastavte granulární oprávnění účtům třetích stran, k nimž se přihlašujete pomocí credentails, pokud je to možné.

  • Využívejte jen taková oprávnění, které jsou pro běh aplikace nezbytně nutné.

  • Např. Google Cloud Platform administrator oprávnění je pro běh aplikace zbytečně vysoké, pokud chcete přistupovat pouze k SQL databázi.

    • V případě úniku credentials to zvyšuje výsledný dopad.

• Změňte credentials a přístupové údaje do systémů v případě odchodu zaměstnanců z IT oddělení.

  • Zejména vývojářů, adminů, bezpečnostních pracovníků, DevOps, atp.

• Proškolte zejména vývojáře v oblasti práce s aplikačními credentials a jejich ukládání.

• Dělejte code review, při kterých se na podobné problémy dokáže přijít.

🎓 Učíme se společně

Co jsme se dozvěděli z přednášek, školení, čtení knih a dalších aktivit?

Finding Security Vulnerabilities through Code Review

• Pořadatel: OWASP DevSlop

• Code review není jen o hledání bugů (ty tvoří jen 15 % chyb) - je o čitelnosti kódu, jeho organizaci, způsobu řešení daného problému (algoritmizace, datové struktury), atd.

  • Je také o sdílení know-how, trasování a trackování, mentoringu, učení se.

• Pokud chceme najít bugy, tak testování je lepší mechanismus než code review.

• Kontrolujeme hlavně byznys logiku, protože ta se velmi těžko kontroluje pomocí automatizovaných nástrojů.

• Nevýhodou je rychlost dodání, slabá kvalita code review, čekání, konflikty, špatný feedback, časová tíseň atd.

• Pokud dám v Googlu něco na code review, do 4 hodin je feature odbavená a nasazená, včetně výměny komentářů atp.

  • Dělají velmi malé změny (max 24 řádků kódu).

    • Striktní coding guide lines.

    • 75% změn je kontrolováno jedním člověkem.

  • Mají takhle nastavenou firemní filozofii, proto je proces tak rychlý.

  • V jiných firmách je to otázka dnů, týdnů a někdy i měsíců.

• Je důležité psát description, aby to reviewera uvedlo do kontextu a nemusel těžce zjišťovat, čeho se code review týká - proč jsem to řešil zrovna takhle, proč to děláme, atd.

• Z výzkumů vyplývá, že čím méně změn je v pull requestu, tím kvalitnější je code review a tím víc chyb a dalších nedostatků bude odhaleno.

• Pro bližší kontext je dobré si funkcionalitu spustit lokálně a vyzkoušet, že všechno funguje tak, jak má.

• Z pohledu security je během code review dobré soustředit se na validaci dat, error handling, logování, autentizaci, správu session, autorizaci a kryptografii.

• Stáhněte si code review checklist.

📰 Co je nového

1. Malicious npm Packages Found Exfiltrating Sensitive Data from Developers

   • NPM obsahuje balíčky navržené k získání citlivých vývojových dat.

   • Všechny tyto balíčky spouští soubor index.js, který odešle získaná data na vzdálený server.

   • Tento soubor se spouští v preinstall kroku.

   • Balíček získává údaje z různých souborů, jako je .idea, .docker, .js, .conf a mnoho dalších.

   • Obsah, který může obsahovat credentials a další údaje, je odeslán jako zip soubor na vzdálený server.

2. China will require all apps to share business details in new oversight push

   • Každý vydavatel aplikací musí s čínskou vládou sdílet své obchodní údaje.

   • Týká se to všech, kteří vystavují své aplikace v rámci jakéhokoli marketu, který v Číně funguje.

   • Regulace prakticky znamená založení firmy v Číně nebo spolupráce s místním zprostředkovatelem.

   • Apple už ze svého marketu spoustu aplikací smazal, aby byl compliant s toutu regulací.

   • Tato regulace se nejspíš dotkne i aplikací typu X, Facebook, Instagram a dalších.

3. Malicious Apps Use Sneaky Versioning Technique to Bypass Google Play Store Scanners

   • Útočníci používají tzv. versioning techniky, kdy první verze aplikace je z bezpečnostního hlediska v pořádku, ale do dalších verzí už je přidaná malware komponenta.

   • Samotný malware je do aplikace vložený pomocí komponenty vzdáleně (pomocí dynamic code loading metody) - to z aplikace udělá backdoor.

   • Tím se obejdou bezpečnostní kontroly Google a samotné odhalení této techniky podle Googlu není jednoduché.

   • Útočníci nejčastěji cílí na uživatelské credentials, data a finance.

4. Mailchimp Suffers Another Security Breach Compromising Some Customers' Information

   • Mailchimp je oblíbený nástroj pro e-mail marketing a posílání newsletterů.

   • Zaznamenal další útok v řadě a umožnil útočníkům přístup do admin a interního rozhraní.

   • Útočník použil techniku sociálního inženýrství na zaměstnance Mailchimpu a jejich kontraktory, čímž se dostal ke credentials.

   • Unikly informace ze 133 zákaznických účtů.

   • Podle všeho nedošlo k úniku jakýchkoli citlivých dat typu hesla, platební údaje atd.

---

😂 Závěrečný ftípek: Knock, knock. “Who's there?" … very long pause … "Java.”

🔔 Sledujte nás na LinkedInu, kam pravidelně sdílíme další novinky a know-how.

🆘 S bezpečností vám rád pomůžu, klidně mi napište - školím vývojáře i management, nastavuju procesy, vyvíjím bezpečné aplikace a poskytuju další služby.