Tuhle službu už podle mne GitHub nabízí několik let, asi teď jenom rozšiřují, pro koho je to dostupné?
Nenašel jsem, jestli se to dá pro konkrétní klíče ignorovat. Když jde o kód manipulující s tajnými klíči (třeba implementace JWT), je dobré mít v testech a příkladech tajné klíče, které slouží pro testovací a výukové potřeby, vznikají speciálně pro ten účel a nikde jinde se nepoužívají.
false positive kvůli testům jsou otravné, mám stovky repositářů a chování githubu mi někdy připadá dost protiuživatelské, nová služba, sám jí zapne, zahltí schránku a uživateli starej se sám.
Na druhou stranu nerozumím tomu, koho napadne dát nějaké přístupový klíč do repositáře a dokonce v takové míře, že na to musí udělat extra službu a informovat o tom.
Napadají mne dva případy, kdy se to může stát a které jsou celkem pochopitelné.
Za prvé, že se tam commitne nějaký testovací klíč k cizí službě, který má třeba platnost jenom měsíc, je tam omezení na 100 záznamů v databázi apod. Prostě něco, čemu člověk nevěnuje tak velkou pozornost, protože je to přeci jen testovací klíč. Jenže i takovéhle testovací prostředí dokáže někdo zneužít.
Druhý případ bude to, že tam někdo commitne ostrý klíč, pak se na to přijde, revertne se to – ale někdo si neuvědomí, že to nestačí, protože to zůstane v historii, odkud si to roboti vytáhnou.
Stalo se mi to. Konfiguracni soubor ve kterem byl i jeden klic/heslo byl sice mimo adresar, ale kdyz jsem chtel updatovat vychozi config, tak jsem ho prekopiroval do repa a neuvedomil si, ze z nej musim neco smazat driv, nez probehl push.
Nastesti to byla one man show hlavne pro me vlastni potreby, takze jsem pak proste prepsal remote historii bez nejakeho boleni hlavy, abych zametl stopy. Ale stat se to muze snadno, obzvlast kdyz si dela clovek review sam sobe.
@...
To máte tak. To si prostě na začátku neuděláte configurační soubor tak jak se má a nedáte ho okamžitě do ignoru tak jak se má a nedej bože to po sobě zkotrolovat. Prostě to někam švihnete a pak se v těch horších případech divíte.
Pak je tu ještě jeden případ. V korporátním světě (viděl jsem) se prostě různé konfigurace a hesla normálně commitovala záměrně a pokud se pokusíte to změnit, nic jiného než průšvih za zmařený čas a potenciální výpadky vás nečeká, a to se vám v tom ještě vedení aktivně pokusí zabránit - protože kterého manažera šetve že to tam bude už 8 rok bez incidentu ... takže se na to vykašlete. Bác a máte to tam. Pak někdo s takovou "practice" začne nějaký public projekt a incident je na cestě ... např. z historie, jak psal F. Jirsák.
17. 12. 2022, 10:31 editováno autorem komentáře
byCx: A teď zkuste v mém původním komentáři najít něco o externích službách. Naopak jsem v jiném vlákně explicitně psal, že je problém i to, když se do repository dostanou klíče k testovacím nebo mock službám.
Jak jsem psal, klíč v repository může být jedině tehdy, když neumožňuje přístup vůbec nikam a používá se jenom v rámci aplikace samotné. Případně to bude náhodně vygenerovaný klíč, který je někde uvedený jako příklad a není nikde zaregistrovaný.
17. 12. 2022, 11:09 editováno autorem komentáře
Ty, které fakt mají zůstat utajeny, samozřejmě v repository nechcete. Jenže pak je potřeba umět GitHubu říct, které utajeny zůstat nemusí. A tedy je má ignorovat. Na což jsem se ptal, zda je to možné. Jak jsem zjistil později, možné to je.
Vidím, že je potřeba to zobecnit. Zkuste se více soustředit na obsah komentářů ostatních, abyste pochopil, co se v nich doopravdy píše. Ten čas, který teď věnujete psaní „odpovědi“, která je úplně mimo, raději věnujte pochopení komentáře, na který jste chtěl reagovat. Nejspíš pak zjistíte, že k vaší odpovědi není důvod.
Ne, existují dobré důvody, proč mít některé klíče v repository, jak jsem psal výše.
Například když píšete parser a serializer klíčů, je nesmysl ty klíče před testem generovat. Nechcete testovat, zda parser rozparsuje klíče serializované vaším serializerem – i bez testu je dost pravděpodobné, že se mu to podaří, protože případné chyby budou na obou stranách stejné. Vy potřebujete otestovat hlavně to, že rozparsuje klíče uložené jinými serializery, a že si nějak poradí i s klíči, které jsou uložené nějak chybně (a které váš serializer s takovou chybou ani neumí vyrobit).
Jednotkový test má totiž testovat právě jednu věc, nemá testovat nic míň ani nic víc. Generování klíčů by byl jen další kód, který se samotným testem nesouvisí, jenom může test znehodnotit.
Pro to, aby bylo možné tu implementaci použít. Privátní klíče se používají ve spoustě aplikací, třeba každý HTPS server pracuje s privátním klíčem, který musí odněkud načíst. O tom, zda je ten privátní klíč zaheslovaný nebo nezaheslovaný, nebyla řeč – protože je to jedno, jestli je uložený nezaheslovaný, nebo je „chráněný“ heslem, které je uložené hned vedle.
Analyzátor hlídá přesně to co hlídat má - jestli se někde nepovalují nezaheslované privátní klíče. Víc po automatickém analyzátoru chtít nejde. Co se týká odstranění nezaheslovaných privátních klíčů z produkčních úložišť (rozdělením na dvě části - zaheslovaný privátní klíč a odjinud dodávané heslo) tak to zabezpečení zvyšuje. Každé z úložišť může mít jiného správce, takže jeden administrátor nedokáže ten privátní klíč ukrást (útoky zevnitř jsou nejčastější).
Zašifrované privátní klíče s heslem uloženým hned vedle jsou také zajímavé. Když analyzátor principiálně obejdete (tj. neurčíte vybrané klíče, které má ignorovat, ale obejdete ho kompletně), bude vám analyzátor k ničemu – protože stejně, jako ho obejdete pro nějaké nedůležité klíče, ho obejdete i pro ty důležité.
Moznosti dekompozicie algoritmu zavisia hlavne na abstraktnom mysleni analytika. Takze prehlasit nieco za dalej nedelitelne je dost diskutabilne.
K tomu aby git dokazal identifikovat privatny kluc, musi byt ulozeny v urcitom formate. K testu ci kod dokaze spravne parsovat format privatneho kluca nepotrebujete realny subor s privatnym klucom.
18. 12. 2022, 12:36 editováno autorem komentáře
Já ovšem nepíšu testy proto, abych si udělal čárku, že existuje test. Píšu je proto, abych ověřil, že daný kód funguje správně. To nejlepší, co můžu v testu udělat, je tedy to, že vezmu privátní klíč uložený jiným programem a zkusím ho načíst. Jakákoli další manipulace s tím souborem, než vstoupí do testu, znamená riziko, že test pokazím a ten bude vracet stav OK, i když kód bude fungovat špatně.
To je vas uhol pohladu. Ten zahrna pokrytie odchyliek mnozstvom suborov s privatnymi klucmi, kde nemate istotu ci mate pokryte vsetky abnormality.
Z mojho uhla pohladu je najlepsie testovat kod proti definici tohoto formatu. Je jedno ci je ta definicia oficialna alebo pokryva aj vystup nejakeho zpraseneho softu.
Proste kazdy podla svojich moznosti.
Rozdíl mezi našimi úhly pohledu je to, že vy jen teoretizujete, zatímco já píšu o zkušenostech z praxe.
Když chcete testovat kód proti definici formátu, tak si nejprve zjistěte, jak taková definice vypadá.
To, že program nebo knihovna, reaguje dobře na abnormality, je dost podstatná výhoda. Určitě mnohem raději používáte program, který vám přesně napíše, kde je chyba a případně i jak ji opravit, než program, který vám prostě napíše, že došlo k chybě a nic dalšího se nedozvíte. Takže testování chování při abnormalitách je užitečné (protože je užitečné mít různé abnormality ošetřené). Přičemž v takovém případě vám definice formátu moc nepomůže, protože obvykle o abnormalitách neříká vůbec nic.
Je to ale správná domněnka. Protože kdybyste někdy něco takového implementoval, o problematice byste něco věděl a nepletl byste si veřejný certifikát s privátním klíčem.
Empirické řešení je také racionální. Vaše „řešení“ bohužel není v souladu s realitou. Dobré testy jsou prakticky vždy empirické. Protože účelem testu není to, abyste to, jak jste problém pochopil, implementoval po druhé (poprvé je to v testovaném kódu). Účelem testu je to, abyste kód ověřil co nejvíce nezávisle na původním kódu – a tím se myslí ne jen samotný kód, ale i analýza, úvahy a předpoklady, které k danému kódu vedly. Když kód testujete na konkrétních příkladech, úplně tím obcházíte to, co si o problému myslíte vy. Nevýhoda takového testu samozřejmě je, že neotestujete všechny možné situace – a výběr toho, které případy budete testovat, je zase zatížen vaší představou o podstatě problému. Což je ale pořád lepší, než zatížit tou představou celý test.
V některých případech, kde je potřeba opravdu silně zajistit správnost (třeba zabezpečovací zařízení na železnici) se to opravdu dělá tak, že se problém řeší nezávisle na sobě dvěma cestami – analyzují to různí lidé, kód píšou různí programátoři. Kód pak běží na dvou různých zařízeních a porovnává se výsledek. Tím je zajištěno, že se „testuje“ opravdu každá varianta. Ale to se dá dělat jen u jednoduchých problémů a ještě jen tam, kde je to opravdu kritické a vyplatí se do toho násobného řešení investovat.
Je to len domienka. To ze ju na zaklade nedostatku informacii pokladate za spravnu, naopak len dokazuje to ze ste vyhradne odkazany na empiricky pristup.
Takze vy si vlasne testami dokazujete len to ci ste spravne pochopil zadanie? Tak to napriklad ADA a obzvlast SPARK nebude to prave orechove, vsak?
I kdyby to byla pravda, nijak to nedokazuje, že vy jenom neteoretizujete.
Jenže ona to ani pravda není. GitHub totiž umožňuje zvolené adresáře ze skenování vyřadit: Excluding directories from secret scanning alerts for users. A jaké uvádějí příklady, proč něco ze skenování vyřadit? „For example, you can exclude directories that contain tests or randomly generated content.“ Nepřipomíná vám to něco?
Plánujete se dál ztrapňovat, nebo si přiznáte, že tu teorii neznáte tak dobře, abyste dokázal rozumně odhadnout, co je potřeba v praxi?
To ze to neumoznuje pochadza od vas z komentaru korym ste toto vlakno zacal. Sorry, zabudol som ze v priebehu diskusie ste schopny niekolko krat otocit, podla toho ako vam to vyhovuje.
To ze ste zistil ze to odignorovat ide neznamena ze ukladanie tych klucov do repozitara je spravna prax, ale len to ze rovnakych patlalov je viac nez by to bolo zdrave.
To ze to neumoznuje pochadza od vas z komentaru korym ste toto vlakno zacal.
Nikoli. „Nevím, zda něco jde udělat“ neznamená „nejde to“.
Sorry, zabudol som ze v priebehu diskusie ste schopny niekolko krat otocit, podla toho ako vam to vyhovuje.
Zkuste najít jediný takový případ.
To ze ste zistil ze to odignorovat ide neznamena ze ukladanie tych klucov do repozitara je spravna prax, ale len to ze rovnakych patlalov je viac nez by to bolo zdrave.
To, že si teoretik, který takový kód nikdy nepsal, myslí, že je to špatná praxe, zase nedokazuje, že to doopravdy je špatně. Označení za patlala od někoho, kdo nezná teorii a nemá žádnou praxi, je kouzelné.
Nevím, jak můžete usuzovat, co dělám s každým svým omylem, z diskuse, kde jsem nic mylného nenapsal.
S tím teoretikem bych to trochu upřesnil – jste špatný teoretik. Podkladem jsou vaše komentáře. Jenže vy to vidět nemůžete – protože jste špatný teoretik.
Například jediné řešení, s kterým jste přišel, je to, že privátní klíče uložíte v nějakém (nejlépe proprietárním) formátu, který GitHub nerozpozná, a vy se pak budete tvářit, že ty klíče v repository vlastně nejsou, i když tam budou.
To nejlepší, co můžu v testu udělat, je tedy to, že vezmu privátní klíč uložený jiným programem a zkusím ho načíst
Je mi líto, ale to je špatná praxe.
V tomto případě máte psát test proti parametrům jaké ten soubor má mít, ne proti tomu co vám vyhodí nějaký program, protože je ten soubor může být špatně. A podrhuji tam tam to slovo "psát".
Pak záleží jak jsou testy organizované, dá se to udělat různě, ale testování pomocí "reálných" vstupů by měly být až uživatelské testy a měly by zahrnovat soubor o kterém bezpečně víte že odpovídá tomu správnému, a soubor který odpovídá tomu špatnému. To proto abyste zajistil, že oba soubory projdou všudy kudy mají a mohl prohlásit feature za plně funkčí. Integrační nebo unit test jsou pouze na půl cesty.
18. 12. 2022, 14:00 editováno autorem komentáře