- Telekom otthoni szolgáltatások (TV, internet, telefon)
- DIGI internet
- Videó stream letöltése
- Álláskeresés, interjú, önéletrajz
- Vodafone otthoni szolgáltatások (TV, internet, telefon)
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- SkyShowtime
- Erőszakos tartalomba fut a gyerek, ha internetezik
- Aliexpress tapasztalatok
- YouTube
Új hozzászólás Aktív témák
-
FTeR
addikt
"a biztonsági réseket a programozók maguk hozzák létre"
Ebbe a megfogalmazásba belekötnék. Egyrészt vannak konfigurálásból fakadó biztonsági rések is, másrészt a biztonsági rés valaminek a hiánya, semmint valami olyan amit szándékosan létrehoznak.Próbálok nem csak a fogalmakon lovagolni, de fontosnak tartom a különbséget. A biztonsági rés gyakorlatilag a hiányos/téves input validálásokból fakad.
A biztonsági rések az idő és az ismeret hiányából maradnka a kódban. Nem mindig hajlandóak azt a plusz időt/erőforrást megfizetni, ami a minőségi kód megírásához kell.
Feltörhetetlen (produktív környezetben használt) kód meg sosem lesz, hiszen mindig találnak új módszereket, amiknek az ismerete a kód írásakor még nem volt meg. -
Attól, hogy ő szeretné magának harácsolni a biztonsági büdzséket, még nem kellene ordas baromságokat mondani, mint pl. a határvédelmet felváltó bullshit. Egy csomó program forráskódjához nem férsz hozzá... ja de. akkor visszavonom
szóval alkalmazásvédelemre csak akkor tudsz figyelni, ha az alkalmazást magadnak fejlesztetted. Amit nem neked fejlesztettek, ott mibe kotorászol?
A magam részéről továbbá nem szeretném, hogy visszajöjjön a 386-os korszak. Amikor 386-an döntenek arról, hogy hogyan kell kódolni egy olyan cégnek, akiket magasról nem érdekel, hogy itt mi van. (lásd: adós a törvényi szabályozással. he?)
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
makayk
csendes tag
"A biztonsági rés gyakorlatilag a hiányos/téves input validálásokból fakad."
Szerintem ehhez a véleményedhez azért ne ragaszkodj
Pl. a buffer overflow-nak a DoS-nak, vagy éppen a root exploitnak mi köze az input alapú validáláshoz?
A cookie session lopá határeset, de ott sem a kódsor hibájáról beszélünk, hanem gyökerekben rejlő technológiai hiányosságról a kényelmes webhasználathoz."A biztonsági rések az idő és az ismeret hiányából maradnka a kódban. "
Akkor egy kódot örök időkig lehetne tökéletesíteni míg megjelenhet. Sőt mégjobb ha a technológiákat is befagyasztjuk, így sose derül ki újabb dolog. -
-
FTeR
addikt
Igazán meghatódtam, hogy a kedvemért regisztráltál
- Buffer overflow ugyan tud alkalmazás saját magai okozni, de hibaként kihasználni csak úgy lehet, ha egy input hatására történik.
- DoS nem biztonsági hiba, az egy túlterheléses támadás, ami ellen kiszolgálási limitek bevezetésével lehet védekezni, server konfigurációs kérdés.
- A root exploit maga egy alkalmazás, aminek a lényege, hogy még az os előtt elindul, ez egy architektúrális dolog, semmi köze a programozáshoz.
- A session lopás nem határeset. függ az adataok letárolásának (a támadónak szügsége van azonosítási adatokra) módjától és az azonosítás megbízhatóságától (ha ez elégtelen, akkor a támadónak publikus adatok is elegek), mindkettő alapvetően programozási kérdés. A session egyáltalán nem webes sajátosság, a süti elnevezésében talán, de technikailag egyáltalán nem az és egyik sem függ a gyökerektől, valójában pont a legfelsőbb szint gyengeségein múlik."Akkor egy kódot örök időkig lehetne tökéletesíteni "
Ez pont így van, ezért vannak a patch-ek. -
sztanozs
veterán
Aki szerint az input validáció a biztonság (informatikai kockázatok kezelésének) alfája és omegája, az szerintem nem igazán foglalkozott még behatóan a témával.
Session/Credential lopásnak (session hijack) semmi köze nincs az input validációhoz. Azért működik, mert:
- nem megbízható a csatorna vagy komprommittálódott a kliens
- nincs megfelelő kliens azonosítás
- nincs replay attack elleni védelem
- visszafejthető vagy kitalálható a session/user azonosító
- nincs jogosultság szegregáció a rendszerben
- csak a rendszer legfelső rétege van megerősítve (csak a nem jogosult "felhasználóktól" félünk)DOS is simán előállhat valid inputokból - ott race condition
Jelszavakat, érzékeny adatokat is lehet plaintextben tárolni, amik később ellophatók (rendszerből, mentésről, hálózati forgalomból).
Rosszul implementált titkosítás is biztonsági probléma, mégsincs köze az input validációhoz.
és még sorolhatnám...
Ja és ma van az infóbiztonság napja
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
Végül is mindegy...[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
sztanozs
veterán
A biztonsági rés gyakorlatilag a hiányos/téves input validálásokból fakad. - végeredményben ezzel vitkoztam.
Egy csomó más oka is lehet egy biztonsági résnek, mint az input-validáció hiánya. A biztonsági réseknek ráadásul csak egy része jön a rossz kódolásból. Nagyon sok biztonsági rés a hibás tervezésból (vagy a tervezés hiányából), vagy a nem megfelelő konfigurációból és - nem programozói - implementációból adódik.- persze én is write only vagyokAmúgy amibe egyáltalán belekötöttél az csak egy gyakran emlegetett poén... Még valakinek az aláírásában is láttam itt egy darabig.
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
A falakon
valaki lovagol a szavakon..
(C) McGesztenyeNyugodtan egy kalap alá veheted a rossz kódolást a tervezés hiányával. A nem megfelelő konfiguráció, vagyis bármiféle konfiguráció az ugyanúgy input a programnak, mint amit képernyőn beírsz. Ugyanúgy validálni kell.
Ha rendesen validáltad az inputot, akkor a többi programozási hibának jóval kevesebb esélye marad, ha egyáltalán marad.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
sztanozs
veterán
Lovaglás - látod pont ezt teszed - és még igazad sincs.
A nem megfelelő konfiguráció, vagyis bármiféle konfiguráció az ugyanúgy input a programnak, mint amit képernyőn beírsz.
Attól még, hogy nem megfelelő a konfiguráció, még lehet szintaktikailag és szemantikailag helyes... Ha egy elavult titkosítási módszert adsz meg, egy rossz jelszót, egy rossz könyvtárat, rosszul állítod be a fájlrendszeri jogosultságokat, debug módban hagyod a programot, nem megfelelő jogokkal futtatod, ez mind lehet helyes adat, de rossz konfiguráció - ezek nagyrésze kódból sem szűrhető (és legtöbbször nincs is értelme).A tervezési hibáknak pedig kb. annyiban van közük a programozáshoz, mint ahogy a mákos bableves készül... Ha szar a recept, akkor szar lesz a kaja is, akármilyen ügyes a szakács.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
nem tökteljesen mindegy, hogy azért rossz a kód, mert helyes speckót rosszul programoztak le vagy azért, mert rossz volt a speckó? hint: de.
"Ha egy elavult titkosítási módszert adsz meg": az elavult titkosítást jelentő inputot nem kell validálni? hint: de. pl. ssh ugat is, ha olyan titkosítást állítok be, ami szerinte elavult.
"rosszul állítod be a fájlrendszeri jogosultságokat": ezért is ugat az ssh.
"debug módban hagyod a programot": ezért is lehet szólni, ha rossz userid-vel futtatod, azért is, pl. az xsane ugat, ha rootként akarod használni.
fentiek szerint, állításoddal ellentétben, mégiscsak szűrik ezek nagy részét.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
Új hozzászólás Aktív témák
- Eladó egy komplett PC (RTX 3070, Ryzen 5 3600, 32GB RAM)
- !! AKCIÓ !! 1 ÉV GARANCIA !! Független Apple Iphone 12 Mini 128GB.
- Samsung Galaxy S23 Ultra 512GB 5G Dual Sim + fólia, Spigen Rugged Armor tok
- Dolby Atmos / DTS:X hangprojektor HT-G700
- Bomba ár! Lenovo Miix 700-12ISK : m7-6G I 8GB I 256GB SSD I 12" QHD Touch I Cam I W10 I Garancia!