Na tomto web serveru nevidím nic obskurního. Spíš naopak.
Jediným významným nedostatkem je téměř nulová portabilita, takže třeba na nějaké malé destičce s ARM si ho nepustíte - a zrovna tam by se hodil.
Soudit kvalitu podle komentářů v kódu... No nevím jestli pánové někdy viděli nějaký opravdový projekt...
Pánové dali do diskuse následující komentáře, aniž by analyzovali, proč tam jsou:
; FIXME: This works, but probably isn't right...
; Not sure what this last null dword is for...
Z toho se, bez analýzy, opravdu nedá usuzovat na bezpečnost či nebezpečnost a je to tak jen pivní hospodský žvást.
Podobných FIXME apod.(včetně různých ToDo...) - nejen v angličtině - jsem viděl spoustu. A nebyly to obyčejné http servery ani nic z klasického IT... třeba to prokazatelně bezpečně a certifikovaně řídilo nějaký zatraceně velký "hardware"... Zatraceně záleží na tom v jakých částech kódu to najdete.
Ten kód http serveru jsem nečetl, tak pochopitelně nemůžu sebejistě tvrdit, že tam nejsou chyby. Dopustil bych se úplně stejné hlouposti jako vy.
Tak jiste, i predskolak ktery nezna pismenka muze napsat zcela funkcni a zcela bezpecny kod. Ten komentar mimo jine poukazuje na to, ze tvurce nevi co dela. A tudiz zaroven i na to, ze o nejake bezpecnosti toho kodu nemuze byt reci. Mozna je, mozna neni, ale pokud je, tak cirou nahodou. Nikoli proto, ze by tu bezpecnost zajistovala schopnost/vedomost.
U libovolneho "bepecneho" kodu totiz alespon ja ocekavam, ze bude kompletne dokumentovan => ze tam neni zadne magicke volani magickych metod, ktere "asi funguji, ale nevim proc".
Ostatne, pokud naprogramuju faktorial jako funci nasobeni, tak to bude fungovat taky ... dokonce i pro zaporne hodnoty. Ze to bude vracet hodnoty mimo obor? Mno takova drobnost me nemuze rozhazet, vzdyt to funguje, nebo ne?
Vůbec nejde o FIXME nebo TODO. Jde o to „nevím, co to dělá“ nebo „asi je to špatně, ale funguje to“. To jsou komentáře, ze kterých se dá velice dobře usuzovat, že to s bezpečností nijak slavné nebude. Přičemž se tady bavíme o bezpečnosti jako odolnosti proti záměrným útokům – je to HTTP server vystavený do internetu. Bezpečné řízení velkého „hardware“, třeba lokomotivy, znamená něco jiného – třeba že vždy zastaví, když strojvedoucí bouchne do velkého červeného tlačítka, nebo že vždy zastaví, když se řídící software dostane do nepředpokládaného stavu.
Já tvrdím „nelze tvrdit, že je to bezpečné“*). Pokud se mnou polemizujete, zbývá vám jenom možnost zastávat tvrzení „je to bezpečné“. Vzhledem k tomu, že jste ten kód – jak sám tvrdíte – ani neviděl, považuji za jasnozřivé spíš vaše tvrzení „je to bezpečné“.
*) Protože samozřejmě nelze úplně vyloučit, že někdo omylem napíše bezpečný kód. Ale rozhodně bych na to nespoléhal.
Vzhledem k tomu že tvrzení "neexistuje bezpečný sofware" (ve smyslu zranitelností) je snad všeobecně uznáváno, tak se snad ani nemá cenu se přít o "je to bezpečné". Možná by se dalo říct, že bezpečný software je ten, který nic neumí, např. za 10 NOPů přeložených do strojového kódu pěkně děkuji.
Je zde zmíněn detail o práci se zásobníkem, která by měla předcházet buffer overflow, což by se za bezpečnější asi dalo označit.
Z komentářů těžko něco usuzovat, může se jednat o "nevím jak to funguje" např. na úrovni komunikačního protokolu, to by pak ovlivnilo spolehlivost, nikoliv bezpečnost, ne?
Just my two cents...
Buffer overflow nesouvisí nutně se zásobníkem. Stack overflow ano, tam můžete přepsat data ale i návratovou adresu. Buffer overflow je o přepsání dat. A dokud ten program nějaká data ukládá, tak tam buffer overflow být může. A zrovna HTTP server se bez ukládání dat neobejde, protože musí z hlavičky dotazu extrahovat alespoň název stránky.
Z komentářů těžko něco usuzovat, může se jednat o "nevím jak to funguje" např. na úrovni komunikačního protokolu, to by pak ovlivnilo spolehlivost, nikoliv bezpečnost, ne?
Právě že to může ovlivnit i bezpečnost. Třeba budu předpokládat, že nějaká dvoubajtová hodnota má vždy v prvním bajtu nulu a nebudu ji vyprazdňovat. Pak tam někdo pošle oba dva bajty vyplněné, já to nevynuluju a stejnou paměť později použiji pro jiný požadavek – a v tom prvním bajtu mi zůstane hodnota z toho prvního požadavku. A už mi unikají data ven. Vypadá to hodně nepravděpodobně, ale jenom do té doby, než někdo vymyslí POODLE útok.
Ono je to jako stavět dům podle plánů, o kterých architekt tvrdí, že ten dům přečká jakýkoliv běsnění živlů beze škody a najít v plánech poznámku u fasády "Nevím, co to udělá v dešti, ale když je to suchý, vypadá to super."
Materiál může, ale nemusí přežit ten liják. Ale je tam riziko, že po prvním dešti opadá fasáda a tvrzení architekta, že dům odolá všem živlům, postrádá dovětek "... akorát nevím, jak se bude fasáda chovat v dešti," A s takovým rizikem rozhodně není nejodolnější.
To jste mne nepochopil. Já kód nezkoumal, jen jsem upozorňoval, že na základě pouze samotného komentáře nemůžete vědět, jestli to má vliv na bezpečnost. Toť vše. Ve vašem příkladě je alfou omegou, že víte, že poznámka se týká fasády, tj. i odolnoti domu... kdyby se poznámka týkala rohožky u dveří, tak to má vztah k odolnoti nula.
No, tu rohožku bych tak rychle neodepisoval. Třebas je pod ní schovaný klíč. Při zničení rohožky by pak mohlo být snadnější si ho všimnout.
Každopádně u AsmHTTPd bude poměrně silná "security by obscurity". Což není v principu špatně, každá další vrstva komplikací pro útočníka se hodí.
ale, okrem toho, že asembler je sakra ťažký na programovanie a ľahko sa naprogramujú chyby, chcel by som vedieť koľko programátorov ten soft
a) testovalo
b) čítalo a rozumelo tomu kódu
c) vedelo čo má hľadať a ako sa prejavujú bezpečnostné chyby?
Veľké korporácie si platia ľudí čo vedia čo majú hľadať (žiaden flame ano!) kým programátori na zelené louce ľudí čo vedia hľadať chyby moc nepoznajú, preto to pošlú do sveta, nech to niekto skontroluje... väčšinou ďalší programátori, ktorý kód píšu ale nevedia ako hľadať chyby... väčšina z nás ani nevie ako taká chyba vyzerá.
preto by som volil slová a ozelenej lúke a najbezpečnejšom web servere opatrnejšie.
Kde autor zpravičky vyčetl, že plně odpovídá http/1.1 a že umí servírovat dinamický obsah?
V repu nic takového v dokumentaci není a co jsem viděl ze zdrojáků tak ani nerozpoznává o jakou metodu se jedná a předpokládá get, načte z hlavičky uri a pokud mu odpovídá nějaký soubor ve webroot tak v podstaťe potom jen dumpne hlavičku a obsah odpovídajícího souboru do socketu.
Kromě omezení na x86_64 je to i omezené jen na Linux.
Jako demonstrace je to pěkné, ale reálné použití je podle mě dost omezené.