21:02
27/3/2017

Problem tzw. screen scrapingu, czyli zautomatyzowanego pobierania treści z serwisów internetowych przez zewnętrzne podmioty i aplikacje jest regularnie podnoszony od kilku lat. Niedawno PKP zablokowało aplikację “Mój pociąg”, która w sposób wygodniejszy niż oryginalny serwis PKP, prezentowała użytkownikom rozkład jazdy pociągów. W przypadku kolei, “scrapowane” dane są informacją publiczną, więc ich pobieranie, przetwarzanie i udostępnianie nie jest problem z kategorii bezpieczeństwa danych. Ale znamy też przypadki scrapingu bardziej niepokojącego. Takiego, który może bardzo źle skończyć się dla użytkowników usług o “scraping” opartych…

Aplikacje finansowe i bolesny scraping

Ze scrapingu korzystają niektórzy pośrednicy w płatnościach. Od swoich klientów żądają loginu i hasła do kont bankowych, a następnie sami logują się na te podane dane i w ramach konta klienta zlecają dyspozycje przelewów. Tacy pośrednicy, mają “przy okazji”, dostęp do wrażliwych informacji na temat danego klienta bankowości internetowej: posiadanych produktów, danych osobowych czy historii transakcji zdradzających preferencje zakupowe klienta (por. Uwaga użytkownicy PayPala, nie korzystajcie z najnowszej funkcji tego serwisu).

Ekran pokazujący się klientom PayPala, którzy chcieli szybko doładować konto

Ekran pokazujący się klientom PayPala, którzy chcieli szybko doładować swoje konto

Chociaż rozwiązanie proponowane przez PayPala, czy wcześniej przez Sofort, ma na celu uprościć użytkownikom procedurę doładowania konta lub płatności za zakupy, to nie tylko wiąże się z przekazaniem loginu i hasła do bankowości internetowej firmie trzeciej — klient łamie także regulamin banku i traci możliwość reklamowania transakcji, które są wykonywane na jego rachunkach.

Dodatkowo, w przypadku udostępniania swojego konta przez podanie loginu i hasła do zewnętrznej usługi, klienci bankowości internetowej nigdy nie mogą mieć 100% pewności, że pośrednik posiadający dostęp do konta, jedyne co zrobi, to zleci transakcję przelewu na uzgodnioną wcześniej kwotę. Pośrednik ma przecież niczym nieograniczony dostęp do wielu dodatkowych informacji:

  • dane osobowe,
  • dane teleadresowe,
  • zakupione usługi,
  • stan majątku,
  • pełną historię transakcji z której można wywnioskować mnóstwo rzeczy na temat posiadacza rachunku,
  • dostęp do danych rachunków, do których klient ma pełnomocnictwo
  • itp.

Na podstawie tego typu informacji łatwo zbudować profil klienta i sprzedawać go dalej. A wszystko to w dalszym stopniu bez udziału i wiedzy klienta. Rozważając najczarniejszy scenariusz, jeśli z jakiegoś powodu skrypty pośrednika przestałyby poprawnie funkcjonować (nie podejrzewamy tu bowiem pośredników o świadome działanie na szkodę swoich klientów, ale warto zauważyć, że problem tego typu może nastąpić np. w wyniku błędu programistycznego lub udanego ataku na infrastrukturę pośrednika), to z konta klienta pośrednik mógłby wyprowadzić wszystkie środki finansowe. A sam użytkownik, ofiara “awarii”, niestety nie mógłby nic z tym zrobić, bo przecież udostępniając login i hasło pośrednikowi utracił wcześniej możliwość reklamacji.

Czy da się ograniczyć takie ryzyko, które dostrzegają nie tylko banki, ale przed którym ostrzega także KNF?

“Unia Europejska dostępu do kont nie zabrania” — to prawda, ale…


Zwolennicy i obrońcy opisanego powyżej podejścia stosowanego przez PayPal i Sofort powoływali się na to, że przecież nadchodząca dyrektywa PSD2 ma dopuścić prawnie dostęp firm trzecich do rachunków klientów w bankach i że w innych krajach Unii Europejskiej, taki dostęp nie jest zabroniony. Mimo to, z uwagi na bezpieczeństwo klientów, KNF wyraźnie ostrzegało banki przed tolerowaniem tego typu praktyk.

Jako rozwiązanie wskazywano wtedy wdrożenie i udostępnianie przez banki API, które powinno umożliwiać korzystanie z poszczególnych funkcji konta bankowego w sposób zapewniający właścicielowi danych — klientowi banku — ścisłą kontrole. I tak oto doczekaliśmy się bardziej szczegółowych informacji odnośnie tego, jak implementowane powinny być rozwiązania sugerowane przez dyrektywę PSD2, gdzie do samego screen scrapingu również się odniesiono — tym razem już wprost.

Dyrektywa PSD2: na co pozwala pośrednikom i jak chroni klientów banków?


Rozwiązania zaproponowane przez regulację PSD2 wprowadzają zmiany umożliwiające m.in. zwiększone bezpieczeństwo w dostępie do danych klientów przez firmy trzecie poprzez zastosowanie mechanizmów powszechnie stosowanych w takich przypadkach (jak oAuth). PSD2 wprowadza także nowe, ciekawe możliwości w kontekście obsługi płatności pomiędzy klientem i sprzedawcą. Pośrednik w płatności lub ogólniej — dostawca zewnętrznej aplikacji (firma trzecia), który jest zarejestrowany jako TPP (Third Party Provider), otrzymuje token na podstawie którego jest mu nadawany dostęp do bankowego API PSD2.

W ten sposób TPP, czyli np. zewnętrzna (nie pochodząca od banku) aplikacja mobilna, nie posiada pełnych uprawnień do konta klienta, bo ten w trakcie logowania do konta zostanie przekierowany na stronę, gdzie określa jakie dokładnie uprawnienia ma otrzymać dana aplikacja. Na przykład, czy może zlecać przelewy, czy może mieć dostęp do historii konta, itp.


Rodzaje dostępu do konta (tzw. XS2A – access to account) zostały rozdzielone na:

  • AIS (account information service)
  • PIS (payment initiation service)

Dzięki takiemu podejściu, klient bankowości internetowej ma pewność, że aplikacja (a dokładniej firma trzecia, czyli TPP), której nada uprawnienia, będzie miała udzielony dostęp jedynie do tych funkcji (operacji) na jego koncie, które są niezbędne do jej działania. I do niczego więcej. Takie podejście eliminuje ryzyko związane ze wspomnianymi na początku naszego artykuły scraperami, które w trakcie zlecania płatności “przypadkiem” pobierają sobie historię transakcji do 5 lat wstecz ;)

Co więcej, zgodnie z PSD2, regulowany jest także czas dostępu do API przez firmę trzecią. Nadawany token nie jest równoznaczny z permanentnym nadaniem uprawnień. Dodatkowo, brak aktywności TPP przez dłuższy czas na rachunku klienta (długość czasu zależna od rodzaju API) skutkować będzie tym, że klient będzie musiał na nowo zautoryzować transakcję/operację poprzez użycie „silnego uwierzytelnienia”.

Specjalne zasady dla tzw. “mikropłatności”

Ciekawym wyjątkiem są mikropłatności, czyli główny „motor napędowy” zmian które spowodowały powstanie regulacji PSD2. Transakcje o niskich kwotach, a zwłaszcza transakcje z zakresu:

  • opłata za parking,
  • za usługi komunikacji miejskiej,
  • za przejazd autostradą,
  • itp.,

nie będą podlegały tak rygorystycznym restrykcjom — a wszystko po to, by zagwarantować maksymalną wygodę dla użytkownika końcowego.

PSD2 – dobra czy zła?


Regulacja PSD2 przez wielu traktowana jest jako zagrożenie dla sektora bankowego (bo musi dzielić się danymi na temat swoich klientów z innymi). Okazuje się jednak, że nie każdy bank patrzy na PSD2 nieprzychylnym okiem. ING Bank Śląski do tematu PSD2 podchodzi bardzo otwarcie, zgadzając się, że wprowadzane przez PSD2 zmiany, będą miał istotny wpływ na kształt bankowości jaką znamy dzisiaj. Jak powiedział nam Roman Tyszkowski, Dyrektor Departamentu Architektury:

W PSD2 widzimy szansę i możliwość wprowadzenia zmian, do których nie tylko będziemy musieli się dostosować, ale które będziemy chcieli wykorzystać. Chcemy dostarczać naszym klientom wygodne rozwiązania, z których chętnie skorzystają, ale tylko pod warunkiem, że nowe formy dostępu do rachunków bankowych zagwarantują odpowiedni poziom bezpieczeństwa, a klient będzie mieć pełną kontrolę nad tym, jakie działania na jego koncie wykonują zewnętrzne aplikacje.

Zhackuj ING Bank przez API! Czyli 24H-CodING

Aby sprawdzić w praktyce, jak dzięki dostępowi API do konta bankowego można uprościć życie klientów, ING postanowił zaprosić do wzięcia udziału w globalnym hackathonie ING 24H-CodING kilkuset uczestników, wśród których pojawią się programiści i eksperci ING z całego świata, studenci, młodzi profesjonaliści i startupy. Hackaton odbędzie sie w Katowicach 12-13 maja (piątek i sobota).

Co ważne, do udziału Bank zachęca nie tylko programistów. W zespołach potrzeba także designerów, “marketingowców” i innych profesjonalistów, którzy mogą pomóc w stworzeniu aplikacji korzystającej z dobrodziejstw API PSD2.

Jak dodaje Tomasz Czakański, Starszy specjalista ds. Architektury:

Na naszym hackathonie nie chcemy stawiać uczestnikom ograniczeń, nie chcemy zamykać się na przykłady zastosowania zdefiniowane jedynie dla banku i przez bank. Liczymy na “hacker’s mind” uczestników — zwłaszcza teraz, w czasach gdzie rozwiązania z zakresu AI, IOT, BigData przestają być jedynie hasłami marketingowymi, a stają się rzeczywistymi rozwiązaniami. Liczymy więc, że na hackathonie pojawi się wiele ciekawych pomysłów, które pomogą nam przystosować się do zmian czekających bankowość, oraz pokażą funkcjonalności, które w najbliższym czasie będziemy mogli wdrożyć dla naszych klientów.

Redakcja Niebezpiecznika pochwala takie “hackerskie” podejście do tematu. Konta bankowe gromadzą wiele danych i dają wiele możliwości, nie tylko związanych z płatnościami. Od niedawna przecież konta w banku służą także jako zweryfikowana tożsamość obywatela i umożliwiają np. składanie wniosków w rządowym programie 500+. Jesteśmy bardzo ciekawi jak i do czego wykorzystają je programiści. Ba! Sami mamy pewien pomysł na aplikację korzystną dla klienta a czerpiącą z nowoczesnych usług lokalizacyjnych wbudowanych w smartphony, czyli tzw. geofencingu.

Wyobraźcie sobie, że wchodząc do danego sklepu (co rozpoznaje moduł GPS w telefonie), momentalnie, pod kątem archiwalnych płatności na rzecz tego sklepu przeszukiwana jest Wasza historia rachunku i kiedy aplikacja stwierdzi, że w ostatnim roku w tym właśnie sklepie wydawaliście najwięcej pieniędzy, to sugeruje Wam, np. poprzez push notification, że powinniście negocjować rabat lub wyrobić kartę zniżkową. Bo nawet mały rabat w skali Waszych tak dużych wydatków pozwoli zaoszczędzić realne kwoty. Albo drugi przykład. Aplikacja do płatności rachunków, która ma podpiętych kilka Waszych kont w różnych bankach i zleca płatność przez ten z rachunków, z którego zostanie pobrana najniższa prowizja w zależności od waluty, kwoty oraz numeru rachunku docelowego.

Zarejestruj się i zgarnij nagrody!

Jeśli chcielibyście zaimplementować któryś z powyższych procesów w ramach aplikacji albo macie swój lepszy pomysł na wykorzystanie bankowego API, to zapraszamy do wzięcia udziału w Hackatonie ING. Hackaton odbędzie sie w Katowicach 12-13 maja (piątek i sobota).

Zarejestrować możecie się na oficjalnej stronie hackatonu 24H-CodING. Warto, bo najlepsze pomysły zostaną nagrodzone!

Nagrodą główną jest wyjazd do miejsca, gdzie tworzy się najnowocześniejsze technologie na świecie, czyli do Doliny Krzemowej. Co więcej, najlepsze pomysły mają też szanse na komercyjne wdrożenie oraz współpracę ich twórców z ING.

Niebezpiecznik objął polską edycję globalnego hackatonu ING 24H-CodING patronatem i na miejscu, zarówno w piątek jak i sobotę, będziemy do Waszej dyspozycji. Nie tylko w celu konsultacji projektów. Będziemy też sędziować. O tym, które z pomysłów będą miały szanse na wygraną decydują bowiem 4 zespoły jurorskie (zasiadamy w jednym z nich). Będziemy mieli ze sobą do rozdania sporo niebezpiecznikowych gadżetów. Jeśli więc jesteście naszymi czytelnikami, znajdźcie nas i przybijcie piątkę!

Zapisy na stronie hackatonu ING 24H-CodING trwają tylko do 31 marca a sama impreza odbędzie się 12 i 13 maja w Starej Walcowni w Katowicach. Nie zostało więc wiele czasu, więc jeśli chcecie leganie pohackować bank (przez API) to rejestrujcie się już teraz! Przypominamy, że nie trzeba być programistą.

Do zobaczenia na miejscu!

PS. Jeśli ktoś chciałby wziąć udział w hackatonie, a brakuje mu osób do zespołu, piszcie w komentarzach (warto tylko podać w komentarzu URL do swojej strony, żeby inni mogli namierzyć Wasz kontakt). Mamy nadzieję, że zrodzi się tu jakaś niebezpiecznikowa drużyna, która godnie powalczy w hackatonie i podeśle nam pocztówkę z Doliny Krzemowej :)

Przeczytaj także:

28 komentarzy

Dodaj komentarz
  1. Nie mam pomysłu ani zespołu, ale jeśli ktoś chciałby doświadczonego Javowca do teamu, to dropnijcie mi maila :)

    • stwórzmy swój team, mam parę pomysłów jak zagarnąć kasę

  2. Szukam Teamu, umiem w C#, ogarniam apki UWP, na co dzień zajmuję się ICT.

    • również C#, formsy i asp.net, uwp na Raspberry, ale ekspertem nie jestem :)

  3. Znam pracę hostów rozliczeniowych banków. Umiejętności programowania słabe ale ogarniam problem od strony działania systemu bankowego. Gdyby ktoś potrzebował ex-pracownika z tej branży to polecam się :)

  4. A jak unie nie zabrania dostępu do rachunków osobom trzecim, to może KNF sejm powinien przyjąć ustawę żę taki operator nielegalnie działa na terenie polski , podobnie jak z firmami hazardowymi?

  5. To teraz czekać, aż ktoś zgłosi na policję, że tego i tego dnia w tym i tym miejscu ktoś będzie wytwarzał i udostępniał narzędzia służące do przełamywania zabezpieczeń zgodnie z Art. 269b. § 1. (który niedawno był tu opisywany) ;)

  6. Trustly dla Paypala nie robil zadnego scrappingu, przeciez dane byly pobierane wprost. Po drugie od DLUGIEGO czasu jest po prostu przekierowanie na strone banku.

    • Ale to chyba tylko w PL tak dziala. W UK podpinasz karte debetowa i/lub ustawiasz Direct Debit na koncie.

    • Po akcji ze scrapingiem PKO BP pozwoliło wreszcie podpiąć kartę do paypal i amazon. Więc poszli po rozum do głowy i kompleksowo rozwiązali sytuację.

  7. Jeżeli ktoś ma jakiś ciekawy pomysł na projekt chętnie go przedyskutuje i wezmę udział. Moją mocną stroną jest Android i Javka, liznąłem też kiedyś HDL jakby ktoś miał pomysł na coś ciekawego na bardzo niskim poziomie. Wszystkie projekty z zakresu rasp/arduino będą bardzo ciekawe. Mogę pomóc również w zakresie krypto(algorytmy, protokoły, PKI), ewentualnie projektowania bezpiecznych rozwiązań ;) Zapraszam do kontaktu!

  8. Wpis sponsorowany?
    Nie mam nic przeciwko, bo jest na niezłym poziomie :)

  9. Przeciez takie hackatony sa po to aby niskim kosztem zdobyć pomysły na nowe funkcjonalności do wdrożenia dla banku. Koszt jaki placi bank jest smiesznie maly, organizacja + “nagrody” takie jak wyjazd do USA… lecz studenci wciąż się bedą zachwycać.

    Gdzies czytalem wywiad przedstawicielem ING ktory sugerowal iz tworcy najciekawszych pomyslow beda mogli być odpowiedzialni za ich realizacje po zlozeniu oferty przez bank. Pomijam juz problem jakim moze byc kradziez pomyslu przez bank, ktore w zasadzie ciezko udowodnic.

  10. Są jakieś nagrody za kradzież bazy “hackatonu ING”?

  11. Na pewno sobie takiej wiadomości na telefonie nie rzyczę. Precz z IoT, profilowaniem i szpiegostwem.

  12. Zabrakło tagu “a r t y k u ł s p o n s o r o w a n y”. I nie mówcie że nie jest, bo jak coś wygląda jak kaczka kwacze (brzmi) jak kaczka to to najprawdopodobniej jest kaczka.

  13. Trochę nie zgadzam się ze wstępem, że w przypadku rozkładu jazdy problem bezpieczeństwa danych nie istnieje. Może w sensie poufności to tak, bo to informacja publiczna (albo informacja sektora publicznego do powtórnego przetworzenia), ale pod kątem innych atrybutów bezpieczeństwa już tak (integralność, dostępność, niezaprzeczalność, autentyczność, etc.). Wg mnie problemem takich aplikacji (ryzykiem) jest np. zjawisko celowej lub przypadkowej dezinformacji. Jeśli z mobilnej apki z rozkładami jazdy, która na “dziko” ciągnie dane korzysta np. 10 tyś pasażerów i z powodu jej wadliwego (lub zamierzonego) działania pokaże im inne dane (np. godziny odjazdów, perony, etc.) to chyba jakiś problem zaistnieje. Może jako pasażer nie zostanę okradziony z danych lub pieniędzy, ale źle poinformowany na pewno (mogę np. spóźnić się na pociąg, którym miałem jechać na lotnisko, a przez to nie wylecieć służbowo na ważne spotkanie). Dlatego problem z bezpieczeństwem chyba istnieje.

    • Nie zgadzam się, że istnieje tu problem bezpieczeństwa. Informację publicznie dostępną (np. rozkład jazdy) zawsze można zweryfikować u źródła. Jeśli ktoś tego nie zrobił i czuje się oszukany, to jest to PEBKAC a nie problem bezpieczeństwa.

  14. C, C++, Swift. Student. Coś tak wiem. Jak zainteresowany to zapraszam do kontaktu.

  15. Ostatnio w sklepie online zgłosił mi się do płatności Sofort, zrobiłem WTF że ktoś chce login/hasło do banku na obcej stronie. Aplikacje mobilne banków ledwo są warte zaufania, ale jak piszecie zostaje ślad i możliwości reklamacji

  16. do ING nie da się normalnie zalogować posiadając token, hasło i login :) bo wymaga to javy której nie mam, oraz starej przeglądarki ją wspierającej. Więc co my tu gadamy o hakowaniu….

  17. Kiedyś znalazłem nieoficjalną aplikację mobilną UsosWeb (systemu używanego przez niektóre uczelnie), ale akurat korzystała z API, a nie scrapingu. Warto sprawdzić, czy producent udostępnia kod źródłowy – dzięki temu można zweryfikować, czy nie wysyła haseł użytkowników na swoje serwery (co w tym wypadku nie jest konieczne).

  18. Toż to śmieszne, dlaczego miałbym tracić swój czas dla komercyjnego Banku, który w dodatku będzie za frytę wykorzystywał moje pomysły, a jako gratyfikację otrzymam mglistą obietnicę jeszcze bardziej mglistej nagrody :)
    Może jakieś konkrety jak w bug bounty

  19. Z tego co wiem to Trustly usunął tą formę autoryzacji w zeszłym roku.

  20. Chciałbym zauważyć, że Trustly w Paypal używa w Polsce do wykonania błyskawicznych przelewów systemu DotPay, a dalej w przypadku mBank mTransferu.

    Wypadało by Niebezpiecznik przed ponownym podaniem takich informacji zweryfikował to najpierw.

    Wykonałem już kilka razy przelew błyskawiczny, i po wybraniu banku i podaniu kwoty zawsze zostałem przeniesiony na stronę DotPay.
    Przelew zawsze był potwierdzany Hasłem SMS dla mTransferu

    • Alez my to wiemy, bo to dzieki burzy jaka rozpetala sie po artykule u nad Paypal zmienil taktyke. W Polsce.

  21. Przestańcie testować i kombinować, bo od czwartku wieczora online’owy ING ma problemy i co chwilę są załamki systemu ;)

  22. czas jakiś temu zgłosiłem im istnienie dość poważnego błędu w ich systemie…zero reakcji…błąd istnieje nadal…ale sorry nikt za darmo nie będzie odwalał roboty za ich it…nagroda ? śmiehu warta może jakiś wygłodzony student się skusi, ale raczej nikt kto na poważnie zajmuje się bezpieczetwem it

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.