Osadzone identyfikatory w adresach URL

Czasami wiadomości rejestracyjne lub anulujące subskrypcję zawierają spersonalizowane adresy URL; na przykład „Aby anulować subskrypcję, kliknij http://www.some-company.com/unusbscribe/? = 12345 ”Problem polega na tym, że kod identyfikacyjny (12345 w przykładzie) można zastąpić dowolnym innym numerem – a niektóre z wygenerowanych numerów anulują subskrypcję innych subskrybentów. Inne niefortunne użycie takiej techniki występuje w wiadomościach e-mail dotyczących uczestnictwa w seminariach internetowych; czasami zakodowany adres URL w wiadomości e-mail przechodzi bezpośrednio na stronę rejestracji z wypełnionymi informacjami – takimi jak dokładna nazwa, adres e-mail i informacje o pracodawcy zaczerpnięte z bazy danych poprzednich kontaktów. Ogólnie rzecz biorąc, złą praktyką jest podawanie tak krótkich identyfikatorów, że użytkownik lub prosty program lub plik wsadowy mogą zostać użyte do usunięcia prawidłowych rekordów w bazie danych lub do zebrania poufnych danych ze strony internetowej. Na przykład, prosty plik HTML w Adobe Acrobat może być użyty do zmuszenia programu do dostępu do każdego adresu URL w pliku; jeśli złoczyńca utworzył, powiedzmy, 20 000 unikalnych identyfikatorów i wszystkie lub większość z nich jest powiązana z prawdziwymi ludźmi, złoczyńca może z łatwością wpłynąć na konta lub zebrać informacje wyświetlane na stronach specyficznych dla klienta. Aby uniknąć takich problemów, utwórz przestrzeń adresową o znacznie większej możliwej wartości identyfikatora niż odwzorowanie rzeczywistych kont 1: 1 na identyfikatory; np. w przypadku listy obejmującej 100 000 osób wartości wygenerowane przez użycie przy użyciu ciągu 20 pozycji z 94 wartościami na pozycję dostępnymi wielkimi, małymi literami, cyframi i znakami specjalnymi, co daje 9420 = 1039 kluczy, znacznie przekraczających wszystko, co może zrobić amator

Pliki cookie i inne zagrożenia po stronie klienta

Inną potencjalną podatnością na zagrożenia dla e-biznesu jest stosowanie plików cookie. Ponieważ HTTP jest protokołem bezstanowym, każda odwiedzana nowa strona WWW nie ma pamięci o ostatniej stronie odwiedzonej przez tego użytkownika. Pliki cookie służą do „utrzymywania stanu” między różnymi stronami odwiedzanymi w danej sesji. Pliki cookie mogą sprawiać, że transakcja e-biznesowa wydaje się płynna, sekwencyjna i skoordynowana. Większość ludzi, omawiając ryzyko związane z plikami cookie, koncentruje się na zagrożeniach prywatności po stronie klienta. Chociaż z pewnością istnieją, pliki cookie stanowią również ryzyko dla firm, które je zatrudniają. Jeśli informacje zawarte w plikach cookie są zaufane, podobnie jak treść w ukrytych polach jest zaufana, e-biznes może być podatny na exploity związane z plikami cookie zwane zatruwaniem plików cookie. Niektóre strony internetowe używają plików cookie do przenoszenia informacji uwierzytelniających dla danego użytkownika, który przegląda jego strony. Gdy użytkownicy się uwierzytelnią, ich token uwierzytelnienia może być przenoszony przez pliki cookie z jednej strony internetowej na wszystkie kolejne strony w tej witrynie. Używanie plików cookie jest dość słabą formą uwierzytelniania. Plik cookie może zostać łatwo skradziony przez osobę szpiegującą lokalną sieć użytkownika lub Internet, a następnie, po uzyskaniu informacji, w celu uzyskania dostępu do osobistych stron użytkownika w Witrynie. W tym celu należy zastosować bezpieczne protokoły, takie jak SSL aby ograniczyć to ryzyko. Pliki cookie są również wykorzystywane do innych celów, które mogą wprowadzić nowe luki w transakcjach o znaczeniu krytycznym. Ponieważ pliki cookie są kontrolowane przez użytkowników końcowych, można je zmieniać w dowolny sposób wybrany przez użytkownika. Jeśli pliki cookie mają na celu instruowanie serwera WWW, gdzie należy zapisać plik specyficzny dla klienta, zmieniając dane cookie, użytkownik końcowy może zastąpić inne pliki klienta lub nawet zastąpić krytyczne pliki systemowe. Podobnie, jeśli pliki cookie są używane do przenoszenia informacji o zamówieniu, co jest powszechne w elektronicznych koszykach, zmiana zawartości plików cookie może zaszkodzić transakcji. Może to spowodować nieautoryzowaną głęboką zniżkę dla klienta. Ten przykład i inne luki w skryptach między witrynami są dość powszechne w dzisiejszej sieci. Exploity przeglądarki, wstrzykiwanie nagłówka HTTP, fałszowanie żądań w różnych witrynach (CSRF) oraz liczne rodzaje phishingu to przykłady ataków klienta / użytkownika WWW. Bez względu na zastosowaną technologię ważne jest sprawdzenie funkcji i funkcji serwerów WWW z krytycznego punktu widzenia bezpieczeństwa. Zależność od konkretnej technologii w transakcjach krytycznych wymaga, aby technologia była godna zaufania, aby nie zapewniała wrażliwych punktów ataku.

Prywatne dokumenty w katalogach publicznych

Prywatne dokumenty przypadkowo umieszczone w publicznym katalogu mogą doprowadzić do naruszenia poufności informacji i utraty prywatności. Na przykład, jeśli plik bazy danych z numerami kart kredytowych (powiedzmy cardnumbers.mdb) był przechowywany w katalogu głównym serwera WWW dla fikcyjnej firmy, mojafirma.com, adres URL wpisany w przeglądarce internetowej mógłby pobrać plik: www.mycompany.com/cardnumbers.mdb

Ryzyko to jest jeszcze większe, jeśli włączone jest przeglądanie katalogów, inna konfigurowalna funkcja. Przeglądanie katalogów umożliwia użytkownikowi końcowemu przeglądanie zawartości systemu plików na danym poziomie katalogu, jeśli strona internetowa nie istnieje o tej samej nazwie. Przeglądanie katalogów jest naprawdę sposobem na eksplorację systemu plików innej witryny za pomocą przeglądarki internetowej. Użytkownicy mogą wyświetlić tę funkcję, jeśli cofną się o jeden poziom z danej strony internetowej, usuwając prawą sekcję adresu URL strony i przeglądając jej katalog wyższego poziomu (np. W http: //abcom/d/e.htm, można usunąć „e.htm”, próbując w ten sposób przeglądać http: // abcom / d /). Atakujący mogą dowiedzieć się wielu cennych informacji podczas przeglądania zawartości katalogu, w tym prywatne pliki. Ponadto sama przeglądarka umożliwia kliknięcie nazwy pliku w strukturze katalogów, co powoduje pobranie pliku. Ponownie, przeglądanie katalogów, jeśli jest włączone, stanowi otwartą lukę i niestety łatwy sposób na pobranie prywatnych lub poufnych informacji

Kodowanie HTML i obejmowanie po stronie serwera

Po skonfigurowaniu serwera WWW tak bezpiecznie, jak to możliwe, ważne jest, aby same strony internetowe nie otwierały luk w zabezpieczeniach. Wielu programistów stron internetowych ma pewne typowe pułapki, które mogą zagrozić bezpieczeństwu witryny. W poprzedniej sekcji wspomniano o problemie polegania na ukrytych polach w HTML dla bezpieczeństwa lub danych krytycznych dla biznesu. Użytkownicy mogą nadużywać danych ukrytych pól w celu obalenia aplikacji. HTML oferuje inne potencjalne luki w zabezpieczeniach. Najczęściej krytykowany jest serwer po stronie (SSI). Opcja konfiguracji SSI, jeśli jest włączona, umożliwia osadzenie dyrektyw w HTML, które serwer wykona. Na przykład, jeśli następna instrukcja została osadzona w dokumencie HTML, poleciłby serwerowi wyświetlenie zawartości pliku haseł systemowych:

<! – # exec / bin / cat / etc / passwd ->

Z pewnością strony internetowe nie powinny być pisane przy użyciu SSI bez ważnego powodu. Chociaż dostęp do kodu HTML jest zwykle pod kontrolą witryny, istnieje wiele sposobów, w jakie osoba atakująca może uzyskać SSI na stronie HTML. Po pierwsze, osoba atakująca mogła znaleźć inną drogę do systemu (np. Poprzez exploit skryptu CGI), ale może chcieć zapewnić łatwiejsze backdoor lub redundantne backdoor na wypadek znalezienia i zamknięcia luki w skrypcie CGI. Po wykorzystaniu skryptu CGI osoba atakująca może wdrożyć dyrektywę SSI na jednej ze stron HTML witryny. Innym sposobem uzyskania dostępu przez atakującego jest wygenerowanie przez serwer strony internetowej z wybranym SSI wbudowanym w HTML. Jak atakujący może to zrobić? Jedno podejście wykorzystuje serwer, który generuje dynamiczny HTML w zależności od danych, preferencji lub historii użytkownika końcowego. Jeśli serwer internetowy wykorzysta niektóre dane atakującego do wygenerowania strony HTML, może on być w stanie wstawić dyrektywę SSI do HTML. Podsumowując, lepszym rozwiązaniem niż ciągłe monitorowanie stron HTML jest po prostu wyłączenie SSI. W takim przypadku, nawet jeśli SSI byłyby osadzone, serwer nie wykonałby ich. Jest to opcja konfiguracyjna i podobnie jak wszystkie pliki konfiguracyjne systemu, plik konfiguracyjny serwera WWW powinien być chroniony zarówno przez ochronę uprawnień do plików, jak i sprawdzanie integralności plików, aby zapewnić, że nie można go sfałszować. Chociaż SSI są często wyróżniane, bardziej powszechne ryzyko wynika z przechowywania dokumentów lub plików w publicznie dostępnej części serwera WWW. Dostępna część serwera WWW nosi nazwę katalogu głównego dokumentu. Ten katalog główny określa część systemu plików, którą serwer Web może odczytać i wyświetlić klientowi Web na żądanie. Katalog główny może być nadzbiorem stron internetowych, które są faktycznie wyświetlane, gdy użytkownik kliknie stronę internetową. W katalogu głównym dokumentu mogą znajdować się inne dokumenty, które nie są powiązane ze stronami internetowymi ani ze stron internetowych. Nie oznacza to jednak, że nie są one dostępne. Podanie poprawnego adresu dla dowolnego dokumentu spowoduje wyświetlenie lub pobranie dokumentu do dowolnego klienta WWW. Na tym polega problem. Warto zauważyć, że treści HTML nie można już znaleźć tylko w plikach obsługiwanych przez Internet. Na lokalnym dysku twardym aplikacje Microsoft Windows często instalują dokumenty Pomocy składające się z plików CHM („chum”) i plików binarnych. Osoba atakująca może wykorzystać tę lukę, co prowadzi do podniesienia uprawnień do strefy „Mój komputer” w systemie Windows XP; niestety lokalne pliki są często pomijane i uznawane za „zaufane” podczas testów penetracyjnych. Uznając te zagrożenia, Microsoft Corp. zaczął używać języka Microsoft Assistance Markup Language w systemie operacyjnym Windows Vista.

Konfiguracja

Kluczem do bezpieczeństwa serwera WWW jest jego konfiguracja. Podobnie jak inne złożone elementy oprogramowania, serwery WWW są wysoce konfigurowalne, aby sprostać potrzebom dowolnej witryny. Domyślnie większość dostawców oprogramowania konfiguruje aplikację pod kątem maksymalnej funkcjonalności, ale minimalnego bezpieczeństwa. Dlatego domyślnie, gdy serwer jest uruchamiany po raz pierwszy, prawdopodobnie będzie bardziej liberalny, niż by tego wymagała polityka bezpieczeństwa danej firmy. Podstawowym założeniem konfigurowalności są różnice występujące między witrynami. Prawidłowo skonfigurowany serwer WWW jest wynikiem zasad, które określają, jaki dostęp jest dozwolony, do jakich osób, dla każdego zasobu. Ta zasada z kolei służy do konfigurowania routerów, zapór i wszystkich serwerów publicznych, takich jak serwer WWW. Skonfigurowanie serwera WWW, choć jest konieczne, w żadnym wypadku nie wystarcza do zabezpieczenia systemu.

Wykorzystuje serwer WWW

Bezpieczeństwo serwera WWW zostało opisane i szczegółowo omówione, w tym między innymi w E-Commerce Security: Słabe linki, Najlepsza ochrona i Książka źródłowa bezpieczeństwa internetowego. W tym miejscu podkreślamy niektóre z typowych exploitów serwerów sieciowych wykorzystywanych przeciwko wielu e-firmom.

Subwersja aplikacji

Ataki polegające na wywróceniu aplikacji nie są często omawiane w odniesieniu do e-biznesu, ale stanowią poważne zagrożenie dla większości aplikacji internetowych. Subwersja aplikacji jest formą niewłaściwego użycia programu. W przeciwieństwie do ataków przepełnienia bufora, ataki subwersji aplikacji wykorzystują logikę programu bez naruszenia integralności programu, w celu podniesienia uprawnień użytkownika i uzyskania nieautoryzowanego dostępu do danych. To właśnie złożoność programu docelowego daje atakującemu możliwość uzyskania nieautoryzowanego dostępu. Ataki subwersji aplikacji wykorzystują programy w sposób, którego projektanci i programiści nie przewidzieli. Zazwyczaj ataki te nie są wykonywane skryptami, ale są opracowywane na podstawie interaktywnego wykorzystania online i późniejszych nadużyć.

Atak subwersji aplikacji będzie próbował odkryć sposoby zwierania ścieżek w przepływie pracy. Na przykład może istnieć ukryta ścieżka, która pozwala użytkownikowi uzyskać dostęp do informacji o koncie bez uwierzytelnienia na tym koncie. Wiele takich ataków działa przy założeniu, że dostęp do poufnych informacji nie jest odpowiednio uwierzytelniony. Kolejny typowy atak wysyła zniekształcone dane wejściowe do programu. Wiele stron WWW często używa formularzy do sterowania aplikacją, podczas gdy dane wprowadzane do formularza są sprawdzane za pomocą skryptów po stronie klienta. Osoba atakująca może skorzystać z faktu, że wielu programistów aplikacji internetowych zakłada, że ​​klient będzie prawidłowo korzystał z formularza i że skrypty sprawdzą wszystkie dane wejściowe wysyłane do witryny. Atakujący może zbadać strumień danych wysłany przez formularz, a następnie, zamiast używać formularza, wysłać zmodyfikowany strumień danych za pośrednictwem adresu URL w przeglądarce lub włączyć go do niestandardowego polecenia wybranego przez atakującego. Osoba atakująca może uzyskać dostęp do aplikacji, umieszczając polecenia systemowe w strumieniu wejściowym. Jeśli strumień wejściowy jest następnie wykorzystywany przez aplikację online w wywołaniu system (), użytkownik końcowy może wymusić wykonanie poleceń systemowych w imieniu atakującego. Niektórzy twórcy aplikacji polegają w dużej mierze na ukrytych polach w dokumencie HTML. Ukryte pola pozwalają twórcy stron internetowych na umieszczenie informacji na stronie, która nie jest wyświetlana, chociaż użytkownik końcowy może zobaczyć dane ukrytego pola po prostu przeglądając źródło HTML. Błędem, który popełniają twórcy aplikacji, jest po pierwsze przekonanie, że użytkownik końcowy nie widzi ukrytych pól, a po drugie, poleganie na integralności danych ukrytych pól przy podejmowaniu decyzji online. Dokonali tego niektórzy kupcy online , błąd polegający na podaniu informacji o cenach produktów w ukrytych polach i wykorzystaniu tych cen do ustalenia kosztu transakcji online. Użytkownik końcowy może po prostu zmienić ceny w ukrytych polach i odesłać niższe ceny do akceptantów w celu zakupu ze zniżką. Innym niewłaściwym wykorzystaniem ukrytych pól jest przekierowanie danych wyjściowych aplikacji. Na przykład niektóre strony internetowe zawierają informacje o ścieżce systemu plików w ukrytych polach na swoich stronach internetowych. Informacje te są wykorzystywane przez skrypt po stronie serwera do określania, gdzie należy czytać lub pisać

Informacja o transakcji. Atakujący, po prostu zmieniając ukryte pole, mogą nadpisywać pliki lub czytać pliki, do których nie powinni mieć dostępu. W niektórych przypadkach może być możliwe zapisanie programu wpisanego w polu formularza, który będzie później używany jako sposób uruchamiania uprzywilejowanej powłoki w systemie zdalnym. Podsumowując, rygorystyczna kontrola jakości oprogramowania jest niezbędna podczas projektowania i rozwoju wszystkich aplikacji internetowych i e-biznesowych, w tym interfejsu użytkownika

Strony internetowe, oprogramowanie pośrednie aplikacji i systemy operacyjne. Gdy oprogramowanie zostanie uznane za odporne na niewłaściwe użycie aplikacji i ataki subwersyjne, administrator systemu musi wykonać inne czynności, aby zapewnić bezpieczeństwo oprogramowania pośredniego dla e-biznesu:

* Wszystkie niepotrzebne skrypty lub programy serwera aplikacji muszą zostać usunięte z serwera produkcyjnego.

* Kod źródłowy oprogramowania pośredniego aplikacji musi być ostrożnie chroniony przed pobraniem lub nieautoryzowanym dostępem.

* Prawidłowa konfiguracja CGI i oprogramowania pośredniego jest niezbędna, aby zapewnić dostęp do wykonywalnego oprogramowania tylko do właściwego oprogramowania pośredniego, z najniższym praktycznym poziomem uprawnień. Należy sprawdzić poprawność danych wejściowych do oprogramowania pośredniego aplikacji, aby upewnić się, że akceptowane są tylko poprawnie sformułowane dane wejściowe.

* Testowanie kodu aplikacji przy użyciu programów takich jak WebInspect firmy SPI Dynamics (www.spidynamics.com), które są specjalnie zaprojektowane do wykrywania wad w aplikacjach internetowych.

Luki w zabezpieczeniach skryptu CGI.

Skrypty CGI są często celem atakujących, ponieważ często są źle skonfigurowane i podatne na niewłaściwe użycie. Projektując skrypty CGI, rozsądne jest oczekiwanie nieoczekiwanego, szczególnie złośliwego ataku. Chociaż projektant stron ma kontrolę nad zawartością skryptów CGI, nie ma kontroli nad tym, co użytkownicy końcowi będą do nich wysyłać. Często pomijane są również podatności skryptów CGI, które istnieją na serwerze w ramach dystrybucji, ale które nie są faktycznie używane w aplikacji. Niektóre skrypty CGI, zawarte w dystrybucji serwera WWW, mają dobrze znane wady, które można wykorzystać w celu uzyskania nieautoryzowanego dostępu do serwera. Nawet jeśli domyślne skrypty CGI nie są używane jako część stron serwera WWW, każdy może uzyskać do nich dostęp po prostu znając nazwy skryptów. Jednym z najczęstszych, ale łatwych do uniknięcia zagrożeń bezpieczeństwa, jest błędna konfiguracja oprogramowania, zwłaszcza skryptów CGI. Jedną z funkcji obsługiwanych przez wiele serwerów Web jest zdolność osób w całej organizacji do pisania skryptów CGI i wykonywania ich z własnych katalogów. Ta funkcja, choć przydatna do porządkowania osobistych stron internetowych, może również powodować zagrożenia bezpieczeństwa systemu. W aplikacjach internetowych serwer sieci Web powinien być skonfigurowany tak, aby uniemożliwić wykonywanie skryptów CGI w dowolnym miejscu poza jednym katalogiem CGI pod kontrolą administratora systemu. Tryb CGI z aliasami skryptów dla serwerów WWW zapewnia, że ​​skrypty CGI będą uruchamiane tylko z jawnie nazwanego katalogu w pliku konfiguracyjnym serwera. Ponadto ścieżka skryptu CGI nie jest nazwana w Uniform Resource Locator (URL) do CGI. Serwer raczej „aliasuje” jawną ścieżkę do skryptu CGI do wybranej nazwy, takiej jak cgi-bin. W ten sposób uruchomienie serwera w trybie CGI z aliasami skryptów zapobiega wykonywaniu nieuczciwych skryptów CGI, a także ukrywa jawną ścieżkę do skryptów CGI. Katalogi skryptów CGI również powinny być poprawnie skonfigurowane przy użyciu kontroli dostępu do systemu operacyjnego. Na przykład, jeśli skrypty CGI są napisane w skompilowanym języku, takim jak C, źródła skryptów powinny zostać wykluczone z katalogu głównego serwera WWW, aby nie można było uzyskać do nich dostępu przez Internet. Powinny być one dostępne tylko dla administratora systemu lub grupy opracowującej treści WWW i niedostępne dla wszystkich

jeszcze w organizacji. Jeśli źródła skryptów wpadną w ręce złośliwych sprawców, kod źródłowy można sprawdzić pod kątem wad, co jeszcze bardziej ułatwia pracę sprawcy. Dostęp do katalogu plików wykonywalnych CGI, często nazywanego cgi-bin, również powinien być odpowiednio kontrolowany. Tylko serwer WWW i administrator potrzebują dostępu do tego katalogu. Liberalne uprawnienia dostępu do katalogu plików wykonywalnych CGI dają złośliwym zamiarom możliwość umieszczania własnych skryptów w witrynie. Większość skryptów CGI jest napisanych w językach skryptowych, takich jak Perl, JavaScript i Python. Języki skryptowe są przydatne do szybkiego prototypowania systemów, ale także pozwalają  programiście bardzo łatwo napisać niebezpieczny kod. Na przykład łatwo jest konstruować polecenia systemowe na podstawie danych wprowadzonych przez użytkownika, co jest potencjalnie niebezpieczną sytuacją. Napisanie tej samej funkcjonalności systemu wymaga kilku linii kodu programowania i znajomości bibliotek systemowych. Łatwa dostępność języków skryptowych sprawia, że ​​są one atrakcyjne, ale także zagraża aplikacjom o kluczowym znaczeniu dla bezpieczeństwa. Ważne jest również, aby zakazać dostępu do tłumaczy z serwera WWW. Na przykład administratorzy systemu mogą ulec pokusie włączenia interpretera Perla do katalogów skryptów CGI; jednak takie działanie zapewnia bezpośredni dostęp do Internetu w celu interaktywnego wykonywania poleceń Perla – niezwykle niebezpieczna konfiguracja. Wreszcie, administratorzy powinni wziąć pod uwagę każdy program CGI na serwerze pod względem jego celu, pochodzenia i modyfikacji. Usuń skrypty CGI, które nie spełniają funkcji biznesowej, i podejrzliwie przeglądaj skrypty CGI, które są dystrybuowane z systemami operacyjnymi i serwerami WWW, pobrane z Internetu lub zakupione komercyjnie. Kroki te wyeliminują większość potencjalnie niebezpiecznych skryptów CGI. Po ustanowieniu stabilnego zestawu programów CGI wykonaj cyfrowy skrót plików wykonywalnych programu (np. Przy użyciu MD5 lub SHA-1), aby umożliwić przyszłe sprawdzanie integralności.

Logika aplikacji biznesowych.

Logika aplikacji biznesowych stanowi jeden z kluczowych obszarów podatności na zagrożenia w systemach e-commerce. Logika programu koduje to, co oferuje firma internetowa pod względem produktów, usług i wygody klientów. Definiuje także wygląd i działanie Witryny oraz zapewnia wszystkie interaktywne funkcje, takie jak dynamiczne strony internetowe, spersonalizowane strony internetowe i możliwości transakcji online. Ponieważ każda aplikacja jest wyjątkowa, oprogramowanie, które implementuje logikę, musi być w wielu przypadkach opracowane na zamówienie dla każdej konkretnej witryny. Natomiast większość innych składników oprogramowania Witryny to komercyjne oprogramowanie gotowe (COTS). Na przykład serwer sieci Web, wewnętrzne bazy danych i oprogramowanie logistyczne dla łańcucha dostaw są często kupowane od dostawców z półki. Dzięki oprogramowaniu COTS użytkownik końcowy nie ma kontroli nad kodem i dlatego nie jest odpowiedzialny za kodowanie poprawek błędów. Po wykryciu błędów oprogramowania w oprogramowaniu COTS sprzedawca oprogramowania zazwyczaj wydaje łatkę lub wprowadza poprawkę błędu w następnej wersji. Dostawcy oprogramowania mogą naprawiać wykryte błędy, ale polegają na witrynach klientów, którzy faktycznie zastosują poprawki lub aktualizacje oprogramowania. W praktyce zdarza się to rzadziej niż jest to pożądane i jest istotnym powodem, dla którego wiele systemów internetowych jest podatnych na zagrożenia.10 Najważniejszym zadaniem w zabezpieczaniu systemów oprogramowania COTS jest upewnienie się, że: (1) są odpowiednio skonfigurowane do bezpiecznej instalacji zgodnie z polityką bezpieczeństwa witryny (2) oprogramowanie jest odpowiednio aktualizowane do bieżącej wersji i poziomu łaty, a (3) administratorzy są świadomi ryzyka związanego z błędami w oprogramowaniu. Ponieważ wiele aplikacji biznesowych jest opracowywanych na zamówienie, zarówno przez wewnętrzny personel, jak i przez outsourcing do programisty e-biznesu, programy stanowią kluczowe ryzyko z kilku powodów. Dynamiczny, interaktywny charakter e-biznesu w połączeniu z coraz bardziej wyrafinowanymi usługami internetowymi wymaga znacznego rozwoju w celu zakodowania logiki. W rezultacie aplikacje są zwykle bardzo złożonymi programami, które mogą zawierać wady i są podatne na ataki przeprowadzane na stronach internetowych. W praktyce błędy w projektowaniu i wdrażaniu logiki aplikacji biznesowych często zagrażają bezpieczeństwu e-biznesu. Tradycyjnie środkowa warstwa oprogramowania jest implementowana na serwerach Web przy użyciu CGI, a ostatnio PHP: Hypertext Processor (PHP). Skrypty CGI i PHP to programy, które działają na komputerze serwera Web jako oddzielne procesy od oprogramowania serwera Web. Serwer sieci Web wywołuje te programy ogólnego przeznaczenia w odpowiedzi na żądania użytkowników. Główną funkcją skryptu CGI / PHP jest przetwarzanie danych wejściowych użytkownika i wykonywanie niektórych usług, takich jak pobieranie danych lub dynamiczne tworzenie strony internetowej dla użytkownika końcowego. Ponieważ skrypty CGI i PHP przetwarzają niezaufane dane wejściowe użytkownika, związane z nimi zagrożenia bezpieczeństwa i inne formy oprogramowania warstwy pośredniej są niezwykle wysokie. Wiele ataków na systemy oparte na sieci Web jest przeprowadzanych przez wyzyskiwane skrypty CGI / PHP. I chociaż skrypty CGI i PHP można pisać w dowolnym języku programowania ogólnego, najczęściej są pisane w językach Perl, C, Tcl i Python. Ostatnio oprogramowanie oparte na komponentach (CBS) zdobywa popularność zarówno w aplikacjach e-commerce, jak i standardowych aplikacjach internetowych. Celem CBS jest rozwój, zakup i ponowne wykorzystanie sprawdzonego oprogramowania w celu szybkiego, łatwego i wysokiej jakości wdrożenia logiki aplikacji. Dwoma bardziej popularnymi strukturami komponentów dla aplikacji e-commerce są Enterprise JavaBeans (EJB) korzystające z XML i Java 2 Enterprise Edition (J2EE), które obsługują Javę opartą na komponentach. Inne modele komponentów obejmują architekturę Common Object Request Broker Architecture (OMBA) grupy Object Management Group (OMG) oraz Common Object Model (COM) firmy Microsoft i COM COM (DCOM). Te struktury komponentów to klej, który umożliwia komponentom oprogramowania korzystanie ze standardowych usług infrastrukturalnych, a jednocześnie ukrywanie szczegółów implementacji przy użyciu dobrze zdefiniowanych interfejsów. Logika aplikacji biznesowych, gdy jest zakodowana w systemach CBS, zwykle działa na serwerach aplikacji z określonymi modelami komponentów, takimi jak EJB, CORBA, COM i DCOM. CBS zapewnia również interfejs do usług zaplecza, takich jak zarządzanie bazą danych, planowanie zasobów przedsiębiorstwa (ERP) i starsze systemy oprogramowania. Oprócz obsługi tradycyjnych funkcji CGI oczekuje się, że oprogramowanie oparte na komponentach umożliwi rozproszone aplikacje między przedsiębiorstwami przez Internet. Paradygmat oprogramowania opartego na komponentach obsługuje również dobrą inżynierię oprogramowania, jak opisano poniżej. Ujednolicony język modelowania (UML) ułatwia analizę obiektową i projektowanie w ramach opartych na komponentach. Ponadto wraz ze wzrostem rynku oprogramowania opartego na komponentach pojawia się wiele standardowych komponentów aplikacji biznesowych któ®e będzie można kupić z półki. Chociaż zalety oprogramowania opartego na komponentach są liczne, stanowią one zagrożenie bezpieczeństwa podobne do tych, jakie dają skrypty CGI. Umożliwia oprogramowanie oparte na komponentach programowania w językach programowania ogólnego przeznaczenia, takich jak Java, C i C ++, które można wykonywać ze wszystkimi prawami i uprawnieniami procesów serwera. Podobnie jak CGI, przetwarzają niezaufane dane wejściowe użytkownika, a ponieważ oprogramowanie oparte na komponentach może być używane do tworzenia wyrafinowanych aplikacji na dużą skalę, prawdopodobieństwo błędów może być nawet większe niż w przypadku prostych skryptów CGI. Niezależnie od implementacji – CGI lub serwerów aplikacji – zagrożenia bezpieczeństwa oprogramowania po stronie serwera są ogromne, dlatego też oprogramowanie po stronie serwera musi być projektowane i wdrażane ostrożnie. Główne zagrożenia w warstwie oprogramowania pośredniego witryn e-commerce to:

Błędna konfiguracja CGI

Domyślne i programistyczne skrypty CGI pozostawione na serwerze produkcyjnym

Niewłaściwe użycie CGI

Subversion aplikacji

Błędna logika

Błędy programowania

Zagrożenia protokołu sieciowego.

Zagrożenia sieciowe wynikają przede wszystkim z wysyłania poufnych danych przez Internet – publiczną sieć z przełączaniem pakietów. Wiele dobrych protokołów dotyczy ryzyka związanego z wysyłaniem poufnych danych przez Internet. Kilka lat temu lista zawierała:

* SET

* SSL

* S / HTTP

* S / MIME

* CyberCash

Chociaż niektóre z tych protokołów są nadal dostępne w takiej czy innej formie, przemysł ogólnie zaakceptował SSL jako protokół wyboru dla bezpiecznych transakcji w przeglądarce internetowej. Celem najbardziej bezpiecznych protokołów sieciowych jest nałożenie warstw zabezpieczeń na warstwy sieciowe TCP / IP. Chociaż protokół TCP / IP zapewnia niezawodne i niezawodne dostarczanie datagramów przez Internet, nie zapewnia poufności, uwierzytelniania ani silnych usług integralności wiadomości. Są to właściwości zapewniane przez bezpieczne protokoły. Niektórzy idą nawet dalej. Na przykład protokoły zgodne z SET pozostawiają zaszyfrowany numer karty kredytowej nawet na stronie sprzedawcy. Ponieważ sprzedawca nie musi znać numeru karty kredytowej konsumenta, ukrywając ten numer przed sprzedawcą, można wyeliminować znaczną część oszustw związanych z kartami kredytowymi. Zamiast odszyfrowywać numer karty kredytowej w witrynie akceptanta, jest on przekazywany w formie zaszyfrowanej od akceptanta do banku wydającego kredyty. Tam jest odszyfrowywany, a konto handlowca jest uznawane za kwotę zakupu. Szczegóły protokołu SET, SSL i innych protokołów handlu elektronicznego są opisane w artykule Bezpieczeństwo handlu elektronicznego: Słabe linki, Najlepsza ochrona, a także w innych książkach. W zależności od potrzeb aplikacji biznesowej online istnieje zapotrzebowanie na mniej lub więcej właściwości bezpieczeństwa zapewnianych przez bezpieczne protokoły. W przypadku większości przeglądarek internetowych bezpieczny protokół nie jest konieczny; wystarczy protokół standardWeb, HTTP. Jednak gdy klienci przesyłają poufne lub osobiste informacje do witryny, preferowany jest bezpieczny protokół, który szyfruje dane. De facto bezpiecznym standardem protokołu jest SSL, teraz zaimplementowany w każdej standardowej przeglądarce internetowej. SSL nie tylko negocjuje tajny klucz sesji między Stroną a klientem w celu zaszyfrowania danych, ale także uwierzytelnia Stronę. Witryna musi mieć ważny certyfikat zatwierdzony przez urząd certyfikacji, któremu użytkownicy domyślnie ufają. Korzystając z listy zaufanych urzędów certyfikacji prowadzonych w przeglądarce klienta, można zapobiec dostępowi do innych niezaufanych witryn. Po ustanowieniu połączenia użytkownik może sprawdzić, czy strona internetowa jest rzeczywiście zgodna z zamierzeniem, sprawdzając certyfikat witryny. Użytkownicy rzadko robią to w praktyce, ale certyfikat jest dostępny i należy go szerzej wykorzystywać. Te bezpieczne właściwości – czyli szyfrowane sesje i uwierzytelnianie strony hosta – służą do większości aplikacji handlu online. Jednak niektóre aplikacje mogą wymagać jeszcze silniejszych usług bezpieczeństwa. Na przykład aplikacje bankowe i inwestycyjne często przesyłają wysoce poufne informacje, z możliwością ogromnych strat finansowych w wyniku nieumyślnego błędu lub celowego oszustwa. Tego rodzaju transakcje wymagają nie tylko poufności danych, ale także uwierzytelnienia klienta. Instytucja finansowa nigdy nie może udzielać dostępu do informacji o koncie ani zezwalać na transakcje bez uwierzytelnienia użytkownika. Typowe schematy identyfikacji w Internecie obejmują proste uwierzytelnianie nazwy użytkownika i hasła. O wiele bezpieczniejszym rozwiązaniem jest wymaganie silnego uwierzytelnienia klienta przy użyciu certyfikatów klienta. SSL obsługuje certyfikaty klienta, chociaż witryny rzadko korzystają z tej możliwości, ponieważ wymaga to od klientów uzyskania certyfikatu od urzędu certyfikacji. W przyszłości protokoły handlu elektronicznego będą musiały być coraz bardziej wyrafinowane, jeśli mają spełniać rygorystyczne wymogi bezpieczeństwa i prywatności nowych aplikacji internetowych. Na przykład, gdy migracyjne, medyczne, patentowe i inne ważne bazy danych migrują do Internetu, protokoły opracowane w celu uzyskania do nich dostępu muszą uwzględniać potrzeby w zakresie bezpieczeństwa i prywatności właścicieli i opiekunów baz danych, a także klienta lub osoby żądającej. Dzisiaj postęp w genomice dostarcza wielu informacji na temat prawdopodobieństwa rozwoju śmiertelnej choroby na podstawie sekwencji genetycznej DNA. Ta wiedza rodzi pytania moralne i etyczne dotyczące tego, ile informacji o potencjalnych chorobach powinna być ujawniona lekarzom i pacjentom, a także podnosi spektrum takich informacji dostających się w niepowołane ręce, gdy są one dostępne w Internecie. Rozważ przypadek, w którym lekarz odpytuje internetową bazę danych chorób genetycznych o sekwencję DNA pacjenta. Aplikacja online próbuje dopasować sekwencję DNA do chorób, które mogą się rozwinąć w przyszłości. Gdyby baza danych była prowadzona przez podmiot komercyjny, taki jak ubezpieczyciel, pacjent prawie na pewno nie chciałby, aby firma wiedziała o jakiejkolwiek chorobie, która mogłaby zostać zwrócona w wyniku zapytania, ponieważ informacje te mogłyby zostać wykorzystane do odmowy ubezpieczenia i zatrudnienie. Podobnie opiekun bazy danych prawdopodobnie nie chciałby wiedzieć o zapytaniu lub jego wyniku, ponieważ taka wiedza może narazić ją na ryzyko w przypadku wycieku informacji. Ponadto opiekun bazy danych chciałby, aby reszta bazy danych pozostała niedostępna, z wyjątkiem określonych wyników zwróconych do zatwierdzonego zapytania. Uniemożliwienie dostępu do jakichkolwiek innych informacji w bazie danych pomogłoby chronić interesy handlowe firmy, ponieważ wówczas bazy danych nie można łatwo powielić. Nie można też zadawać pytań bez mechanizmu śledzenia kosztów. Aby wesprzeć ten podwójny model bezpiecznego i prywatnego dostępu do informacji, należy opracować i wprowadzić na rynek protokoły handlu elektronicznego, które nie tylko szyfrują przesyłane dane, ale także uwzględniają całkowite potrzeby w zakresie bezpieczeństwa i prywatności obu stron transakcji. Kolejny obszar aplikacji handlu elektronicznego, który będzie wymagał lepszych protokołów bezpieczeństwa i prywatności, obejmuje aplikacje akceptujące płatności elektroniczne lub elektroniczne. Obecnie większość schematów płatności online korzysta z kart kredytowych lub debetowych, przy czym płatności są dokonywane z konta czekowego kupującego w banku. Płatności są dokonywane za pomocą weryfikacji środków online lub płatności partiami w trybie off-line na koniec dnia. Tworzonych jest wiele aplikacji, zwłaszcza dotyczących płatności w wysokości kilku dolarów, a nawet groszy, które nie są w stanie pokryć kosztów transakcji bankowej. Wiele komercyjnych usług i produktów, takich jak automaty vendingowe i parkomaty, są aktywowane monetami i nie wymagają od klientów posiadania konta ani linii kredytowej. Chociaż podejmowane są wysiłki w celu przekształcenia takich usług w urządzenia skomputeryzowane, z możliwością mikropłatności, upłynie wiele lat, zanim zostanie to faktycznie zrealizowane. W każdym razie zawsze znajdą się klienci, którzy chcą zapłacić gotówką lub jej ekwiwalentem elektronicznym, aby transakcja nie mogła być śledzona przez osobę trzecią, takich jak bank lub wierzyciel. Nowsze aplikacje online do mikropłatności mogą obejmować pobieranie opłat za pobieranie muzyki, dane, prognozy pogody, notowania giełdowe, artykuły z czasopism i strony z książek. Wiele z tych aplikacji jest obecnie udostępnianych bezpłatnie i wspieranych przez banery reklamowe, ale troska o zyski motywuje większość stron internetowych do poszukiwania dodatkowych źródeł dochodów. Niezależnie od zastosowania, potrzebne są alternatywy gotówkowe w stosunku do obecnego systemu płatności na rachunku bieżącym. Kluczowe obawy związane z bezpieczeństwem i prywatnością polegają na zapewnieniu, że e-gotówka jest właściwie wydawana i rozliczana oraz że zachowana jest anonimowość. Z myślą o tych celach opracowano kilka protokołów, ale żaden nie osiągnął komercyjnego sukcesu ani nie został przyjęty przez społeczność dostawców. Ponieważ mobilny handel elektroniczny zaczyna prowadzić bardziej tradycyjnie transakcje gotówkowe (np. parkomaty, automaty i kasy biletowe), dostawcy usług bezprzewodowych mogą przyjąć te nowe cyfrowe protokoły kasowe. Niezależnie od protokołu sieciowego używanego w aplikacji e-commerce, kluczową kwestią są osoby atakujące, które będą próbowały przełamać najłatwiejszą przeszkodę w dążeniu do uzyskania uprawnień systemowych i nieautoryzowanego dostępu do danych. postrzegani jako silni, atakujący będą szukać alternatyw, które omijają bezpieczeństwo sieci. Na przykład tego rodzaju standardowe ataki z zestawu narzędzi hakera omijają zabezpieczenia zapewniane przez większość protokołów e-commerce:

* Ataki typu man-in-the-middle. Przechwytywanie transmisji w tranzycie w celu podsłuchu lub fałszowania

* Ataki DNS. Zmiana rekordów w światowym systemie nazw domen w celu przekierowania połączeń do niewłaściwych adresów

* War dialing. Zautomatyzowane testowanie każdego numeru telefonu w bloku liczb

* Wykorzystywanie luk w zabezpieczeniach oprogramowania w usługach sieciowych. Takie jak serwery FTP, Bind, SMTP i HTTP

* Dostęp wewnętrzny. Niewłaściwe korzystanie z autoryzowanego dostępu przez osobę z zewnątrz (pracownika, kontrahenta)

* Wykorzystanie zaufanych hostów. Atak z innego systemu, który ma uprzywilejowaną relację z systemem docelowym

* Ataki kryptograficzne Brute-force. Zautomatyzowane testowanie wszystkich możliwych kluczy odszyfrowywania w celu odszyfrowania tekstu zaszyfrowanego

Podsumowując, ważne jest nie tylko wybranie odpowiedniego protokołu sieciowego dla każdej aplikacji online, ale także unikanie fałszywego poczucia bezpieczeństwa, które mogłoby wynikać z używania „bezpiecznego” protokołu sieciowego. Dobra inżynieria bezpieczeństwa weźmie pod uwagę luki w innych elementach systemu, które są bardziej atrakcyjnym celem dla zdeterminowanych hakerów.