Skomentuj:
Aby ocenić zaloguj się lub zarejestrujX
Takie zestawienie zostało już opublikowane po raz drugi (pierwsza lista pojawiła się rok temu) - jej autorami są eksperci ds. bezpieczeństwa informatycznego z MITRE Corporation, Sans Institute, amerykańskiej Agencji Bezpieczeństwa Narodowego oraz działającego w ramach Departamentu Bezpieczeństwa Wewnętrznego zespołu National Cyber Security Division. Na liście nie znalazły się jakieś konkretne dziury w popularnych aplikacjach - umieszczono na niej pewne typy błędów, szczególnie często popełnianych przez programistów. Im błąd popularniejszy i bardziej niebezpieczny dla systemu lub użytkownika, tym wyższą pozycję zajął na liście.
Warto zauważyć, że pierwsze trzy pozycje na liście - błędy typu XSS (czyli cross-site scripting), SQL injection oraz buffer-overflow - są odpowiedzialne za zdecydowaną większość wszystkich ataków informatycznych, robaków, trojanów itp., które w ciągu ostatnich lat pojawiły się w Sieci. Najgorsze jest to, że wszystkie te błędy są stosunkowo łatwe do uniknięcia - pod warunkiem, że autorzy oprogramowania będą trzymali się kilku podstawowych zasad tworzenia i testowania kodu. Niestety, praktyka pokazuje, że tak nie jest... Dowodem jest choćby najnowsza luka w Google Buzz.
Pierwsza trójka
Pierwszą pozycję na liście zajęły luki typu XSS - czyli proste błędy popełniane przez twórców serwisów WWW. W skrócie rzecz ujmując, problem polega na tym, że złe skonfigurowanie serwisu umożliwia nieautoryzowanemu użytkownikowi umieszczenie na stronie niebezpiecznego kodu. Dlaczego akurat ten błąd znalazł się na pierwszym miejscu? Prawdopodobnie dlatego, że znacznie ułatwia on pracę autorom złośliwego oprogramowania - ponieważ umożliwia osadzenie złośliwego pliku (np. trojana) na stronie, która teoretycznie wydaje się bezpieczna. Jeszcze kilka lat temu najprostszym sposobem na "złapanie" jakiegoś wirusa było odwiedzenie jakichś podejrzanych serwisów - stron z porno, crackami, warezem itp. Teraz jest inaczej - wirus równie dobrze może pochodzić z popularnego sklepu internetowego, portalu lub e-banku (właśnie za sprawą luk typu XSS).
Zaraz za XSS uplasowały się błędy przepełniania bufora - takie luki są szczególnie niebezpieczne, bo umożliwiają zmuszenie systemu (lub aplikacji) do uruchomienia dowolnego podsuniętego jej kodu. Swego czasu słynął z nich Microsoft - ale ostatnimi czasy takie błędy wykrywane są praktycznie we wszystkich popularnych systemach i aplikacjach. "Buffer-overflow" to też zwykle efekt niedbałości lub niekompetencji programisty - bo stosunkowo łatwo można je wyeliminować na etapie tworzenia kodu.
Na trzecim miejscu znalazły się błędy typu SQL injection - angielska nazwa jest bardzo trafna, bo luka polega właśnie na pozostawieniu możliwości "wstrzyknięcia" do bazy danych złośliwego kodu (zapytania SQL), który może potem zostać automatycznie wykonany. I podobnie jak w dwóch poprzednich przypadkach (oraz 22 kolejnych z listy), ta luka pojawia się zwykle tam, gdzie tworzący aplikację programista poszedł na skróty lub po prostu zapomniał o zasadach bezpieczeństwa.
Na kolejnych miejscach uplasowały się m.in. błędy związane z autoryzacją dostępu do chronionych zasobów, kontrolą niedostateczną kontrolą wprowadzanych danych czy niewłaściwego przekierowywania zapytań URL. Pełną listę można znaleźć w serwisie Cwe.mitre.org.
"Rozliczajcie autorów oprogramowania"
W oświadczeniu wydanym przez autorów zestawienia znalazła się pewna bardzo ciekawa propozycja - zaapelowali oni do klientów biznesowych, by wymuszali na dostawcach oprogramowania stosowanie praktyk bezpiecznego tworzenia kodu. Sposobem ma być... rozliczanie kontrahentów z błędów w oprogramowaniu oraz problemów, które z owych błędów mogą wynikać.
Pomysł jest dość ciekawy - choć nie jest nowy. Taka idea pojawia się regularnie od kilku lat, i jakoś do tej pory nikt nie zdecydował się na jej wprowadzenie w życie. Przede wszystkim dlatego, że takim rozwiązaniem nie sa zainteresowani... sami zainteresowani, czyli twórcy oprogramowania.
Truizmem będzie stwierdzenie, że program bez błędów nie nigdy nie powstał i nie powstanie - to wie przecież każdy, kto ma jakiekolwiek pojęcie o tworzeniu oprogramowania. Zawsze znajdą się jakieś luki, zaś stosowanie zasad bezpiecznego tworzenia kodu jest jedynie sposobem na zminimalizowanie ich liczby.
To się da zrobić?
Do tej pory jednak wszelkie propozycje w tym zakresie były dość mało konkretne i demagogiczne - mówiło się zwykle o wprowadzeniu jakiejś formy odpowiedzialności (np. finansowej) producenta za wszelkie luki w oprogramowaniu. I nic dziwnego, że na to producenci nie chcieli się zgodzić - bo typów luk są setki i nie ma sposobu, by na etapie tworzenia oprogramowania zabezpieczyć się przed nimi wszystkimi. Dowodem są cyklicznie udostępnianie poprawki dla Windows, Mac OS X, najróżniejszych dystrybucji Linuksa, Solarisa, Adobe Readara, Firefoksa, Opery, Chrome'a itp. itd.
Ale nowa propozycja wydaje się dużo bardziej przemyślana i faktycznie może mieć szansę na zrealizowanie. Autorzy listy nie chcą bowiem, by producenci byli rozliczani ze wszystkich błędów - zamiast tego sugerują firmom, by w kontraktach z dostawcami oprogramowania żądali gwarancji, że w gotowym produkcie nie ma błędów z owej listy. Czyli luk, które powstają zwykle w wyniku jakichś zaniedbań, pomyłek czy zwykłej ignorancji. A to się chyba da zrobić...
Czytaj więcej na technologie.gazeta.pl
Warto zauważyć, że pierwsze trzy pozycje na liście - błędy typu XSS (czyli cross-site scripting), SQL injection oraz buffer-overflow - są odpowiedzialne za zdecydowaną większość wszystkich ataków informatycznych, robaków, trojanów itp., które w ciągu ostatnich lat pojawiły się w Sieci. Najgorsze jest to, że wszystkie te błędy są stosunkowo łatwe do uniknięcia - pod warunkiem, że autorzy oprogramowania będą trzymali się kilku podstawowych zasad tworzenia i testowania kodu. Niestety, praktyka pokazuje, że tak nie jest... Dowodem jest choćby najnowsza luka w Google Buzz.
Pierwsza trójka
Pierwszą pozycję na liście zajęły luki typu XSS - czyli proste błędy popełniane przez twórców serwisów WWW. W skrócie rzecz ujmując, problem polega na tym, że złe skonfigurowanie serwisu umożliwia nieautoryzowanemu użytkownikowi umieszczenie na stronie niebezpiecznego kodu. Dlaczego akurat ten błąd znalazł się na pierwszym miejscu? Prawdopodobnie dlatego, że znacznie ułatwia on pracę autorom złośliwego oprogramowania - ponieważ umożliwia osadzenie złośliwego pliku (np. trojana) na stronie, która teoretycznie wydaje się bezpieczna. Jeszcze kilka lat temu najprostszym sposobem na "złapanie" jakiegoś wirusa było odwiedzenie jakichś podejrzanych serwisów - stron z porno, crackami, warezem itp. Teraz jest inaczej - wirus równie dobrze może pochodzić z popularnego sklepu internetowego, portalu lub e-banku (właśnie za sprawą luk typu XSS).
Zaraz za XSS uplasowały się błędy przepełniania bufora - takie luki są szczególnie niebezpieczne, bo umożliwiają zmuszenie systemu (lub aplikacji) do uruchomienia dowolnego podsuniętego jej kodu. Swego czasu słynął z nich Microsoft - ale ostatnimi czasy takie błędy wykrywane są praktycznie we wszystkich popularnych systemach i aplikacjach. "Buffer-overflow" to też zwykle efekt niedbałości lub niekompetencji programisty - bo stosunkowo łatwo można je wyeliminować na etapie tworzenia kodu.
Na trzecim miejscu znalazły się błędy typu SQL injection - angielska nazwa jest bardzo trafna, bo luka polega właśnie na pozostawieniu możliwości "wstrzyknięcia" do bazy danych złośliwego kodu (zapytania SQL), który może potem zostać automatycznie wykonany. I podobnie jak w dwóch poprzednich przypadkach (oraz 22 kolejnych z listy), ta luka pojawia się zwykle tam, gdzie tworzący aplikację programista poszedł na skróty lub po prostu zapomniał o zasadach bezpieczeństwa.
Na kolejnych miejscach uplasowały się m.in. błędy związane z autoryzacją dostępu do chronionych zasobów, kontrolą niedostateczną kontrolą wprowadzanych danych czy niewłaściwego przekierowywania zapytań URL. Pełną listę można znaleźć w serwisie Cwe.mitre.org.
"Rozliczajcie autorów oprogramowania"
W oświadczeniu wydanym przez autorów zestawienia znalazła się pewna bardzo ciekawa propozycja - zaapelowali oni do klientów biznesowych, by wymuszali na dostawcach oprogramowania stosowanie praktyk bezpiecznego tworzenia kodu. Sposobem ma być... rozliczanie kontrahentów z błędów w oprogramowaniu oraz problemów, które z owych błędów mogą wynikać.
Pomysł jest dość ciekawy - choć nie jest nowy. Taka idea pojawia się regularnie od kilku lat, i jakoś do tej pory nikt nie zdecydował się na jej wprowadzenie w życie. Przede wszystkim dlatego, że takim rozwiązaniem nie sa zainteresowani... sami zainteresowani, czyli twórcy oprogramowania.
Truizmem będzie stwierdzenie, że program bez błędów nie nigdy nie powstał i nie powstanie - to wie przecież każdy, kto ma jakiekolwiek pojęcie o tworzeniu oprogramowania. Zawsze znajdą się jakieś luki, zaś stosowanie zasad bezpiecznego tworzenia kodu jest jedynie sposobem na zminimalizowanie ich liczby.
To się da zrobić?
Do tej pory jednak wszelkie propozycje w tym zakresie były dość mało konkretne i demagogiczne - mówiło się zwykle o wprowadzeniu jakiejś formy odpowiedzialności (np. finansowej) producenta za wszelkie luki w oprogramowaniu. I nic dziwnego, że na to producenci nie chcieli się zgodzić - bo typów luk są setki i nie ma sposobu, by na etapie tworzenia oprogramowania zabezpieczyć się przed nimi wszystkimi. Dowodem są cyklicznie udostępnianie poprawki dla Windows, Mac OS X, najróżniejszych dystrybucji Linuksa, Solarisa, Adobe Readara, Firefoksa, Opery, Chrome'a itp. itd.
Ale nowa propozycja wydaje się dużo bardziej przemyślana i faktycznie może mieć szansę na zrealizowanie. Autorzy listy nie chcą bowiem, by producenci byli rozliczani ze wszystkich błędów - zamiast tego sugerują firmom, by w kontraktach z dostawcami oprogramowania żądali gwarancji, że w gotowym produkcie nie ma błędów z owej listy. Czyli luk, które powstają zwykle w wyniku jakichś zaniedbań, pomyłek czy zwykłej ignorancji. A to się chyba da zrobić...
Czytaj więcej na technologie.gazeta.pl
