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 checklist zdarma.

---

🏆 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ádi pomůžeme, klidně nám napište - školíme vývojáře i management, nastavujeme procesy, vyvíjíme bezpečné aplikace a poskytujeme další služby.