Testowanie bezpieczeństwa aplikacji mobilnych

76
Testowanie bezpieczeństwa aplikacji mobilnych Sławomir Jasek

Transcript of Testowanie bezpieczeństwa aplikacji mobilnych

Page 1: Testowanie bezpieczeństwa aplikacji mobilnych

Testowanie bezpieczeństwa aplikacji mobilnych

Sławomir Jasek

Page 2: Testowanie bezpieczeństwa aplikacji mobilnych

Dzień dobry!

Pentester / konsultant bezpieczeństwa

Sławomir Jasek

Od 2003 roku:Ocena bezpieczeństwa aplikacji, systemów, sieci...Najskuteczniej pomagamy już od etapu projektowania.

Page 3: Testowanie bezpieczeństwa aplikacji mobilnych

Co będzie● Spojrzenie pentestera (= intruza) na aplikacje mobilne ● Testowanie – na przykładach głównie Android

– Analiza paczki i kodu– Dane zapisywane w urządzeniu i w logach– RPC– Transmisja– API

● Podsumowanie

Page 4: Testowanie bezpieczeństwa aplikacji mobilnych

Aplikacja mobilna – spojrzenie intruza

RPC

SIEĆ

ZAPIS DANYCH

UŻYTKOWNIK

OS

Page 5: Testowanie bezpieczeństwa aplikacji mobilnych

Jak?Inna aplikacja na urządzeniu

Kradzież, zgubienie urządzenia, przypadkowy dostęp, inna aplikacja...

Podatności systemu

Social engineering,słabości użytkownikównp. słabe hasło, zbyt trudne mechanizmy

Ataki na transmisję - podsłuch, słabości SSL

API – błędy kontroli dostępu, logiczne, konfiguracji...

Analiza paczki

Page 6: Testowanie bezpieczeństwa aplikacji mobilnych

Kto?„grubszy cwaniak”

„script-kiddie”

Krzysztof Jarzynaze Szczecina

Dorwał się do narzędzi,wali na oślep, zwykle nie bardzo rozumiejąc co się dzieje.

Coś mu się przypadkiem udało (lub nie), i afera gotowa.

Ma motywację, zasoby oraz możliwości przeprowadzenia ataku nakierowanego

Page 7: Testowanie bezpieczeństwa aplikacji mobilnych

Po co?

● Jak to po co? Bo może!

● Dla sławy!● Dla satysfakcji● Dla pieniędzy● Dla innych korzyści● ...

https://www.flickr.com/photos/viirok/2498157861

Page 8: Testowanie bezpieczeństwa aplikacji mobilnych

Paczka aplikacji

PLAY / STORE

Page 9: Testowanie bezpieczeństwa aplikacji mobilnych

Paczka aplikacji

● Android– Aplikacje bez root

np. „My App Sharer”– APK Leecher– Playdrone – masowe

pobieranie do chmury– (nie wspominając root)

● iOS, inne – DRM nie jest problemem

Page 10: Testowanie bezpieczeństwa aplikacji mobilnych

Rozpakowanie, dekompilacja...

Page 11: Testowanie bezpieczeństwa aplikacji mobilnych

Analiza kodu

● Do ataku jakiegoś procesu przydaje się rozumieć jak on działa

● Własna kryptografia, błędy implementacji...● Hasła, klucze, tokeny zaszyte w aplikacji

Np. tokeny FB, Google, MS, Yahoo i Linkedin aplikacji Airb2b – 10 milionów użytkowników

http://viennot.com/playdrone.pdf

● Tak, znaleźliśmy token FB w aplikacji ;)

Page 12: Testowanie bezpieczeństwa aplikacji mobilnych

Przykład● Przesyłanie mailem danych do „bazy” –

[email protected]● Założenie : wysyłamy bezpośrednio przez nasz serwer

pocztowy – mail.pewnafirma.com, nie angażujemy kont użytkownika

● Serwer oczywiście nie jest open-relayem, do wysłania maila wymaga uwierzytelnienia

● Hasło zaszyte w aplikacji● Co możemy zrobić? (oprócz wysyłania spamu)

To samo hasło do POP3 = dostęp do skrzynki!

Page 13: Testowanie bezpieczeństwa aplikacji mobilnych

Wytęż wzrok i znajdź klucz „szyfrujący”w zaobfuskowanym kodzie

public final class a     implements b {     private static final char[] a = { 67,72,65,82,84,79,83,67,72,76,85,68,78,73,69 };

    private static void a(char[] paramArrayOfChar, char paramChar)     {         paramArrayOfChar[0] = paramChar; int i = 0;         if (i < paramArrayOfChar.length)         {             if (i % 2 == 0) { paramArrayOfChar[i] = a[(i % a.length)]; }             for (;;)             {                 i++; break; paramArrayOfChar[0] = paramChar;             }         }     }

Page 14: Testowanie bezpieczeństwa aplikacji mobilnych

Wytęż wzrok i znajdź klucz „szyfrujący”w zaobfuskowanym kodzie

public final class a     implements b {     private static final char[] a = { 67,72,65,82,84,79,83,67,72,76,85,68,78,73,69 };

    private static void a(char[] paramArrayOfChar, char paramChar)     {         paramArrayOfChar[0] = paramChar; int i = 0;         if (i < paramArrayOfChar.length)         {             if (i % 2 == 0) { paramArrayOfChar[i] = a[(i % a.length)]; }             for (;;)             {                 i++; break; paramArrayOfChar[0] = paramChar;             }         }     }

„CHARSCHLUDNIE”

Page 15: Testowanie bezpieczeństwa aplikacji mobilnych

Manifest, analiza uprawnień...

Page 16: Testowanie bezpieczeństwa aplikacji mobilnych

Dane zapisywane na urządzeniu

Kradzież, zgubienie urządzenia, przypadkowy dostęp, inna aplikacja...

Page 17: Testowanie bezpieczeństwa aplikacji mobilnych

Jak to sprawdzić● Ręcznie: adb pull na różnych etapach pracy aplikacji

• Automaty, skrypty – np. wrzucanie do svn

Page 18: Testowanie bezpieczeństwa aplikacji mobilnych

Uprawnienia plików

Page 19: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache...● Dość często zawierają pełne żądania HTTP,

wprowadzane klawisze – np. hasło użytkownikaINSERT INTO "cfurl_cache_response" VALUES(2,0,1594297610,0,'http://dev/service/auth/createFirstSession?password=35971831&sessionId=857006 &userId=24384344','1970-01-21 23:03:36');

Page 20: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache...● Dość często zawierają pełne żądania HTTP,

wprowadzane klawisze – np. hasło użytkownikaI/System.out( 1098): BaseActivity calling: /login onResponseData: {"response":{"mask":"c794ffa2ffbdffc180ff41ff","phi":"/(...)D/InputEventConsistencyVerifier( 1098): 0: sent at 6529438000000, KeyEvent { action=ACTION_UP, keyCode=KEYCODE_3, scanCode=4, metaState=0, flags=0x8, repeatCount=0, eventTime=6529438, downTime=6529371, deviceId=0, source=0x301 } D/InputEventConsistencyVerifier( 1098): 0: sent at 6532144000000, KeyEvent { action=ACTION_UP, keyCode=KEYCODE_5, scanCode=6, metaState=0, flags=0x8, repeatCount=0, eventTime=6532144, downTime=6532032, deviceId=0, source=0x301 } D/InputEventConsistencyVerifier( 1098): 0: sent at 6534378000000, KeyEvent { action=ACTION_UP, keyCode=KEYCODE_7, scanCode=8, metaState=0, flags=0x8, repeatCount=0, eventTime=6534378, downTime=6534277, deviceId=0, source=0x301 } D/InputEventConsistencyVerifier( 1098): 0: sent at 6536876000000, KeyEvent { action=ACTION_UP, keyCode=KEYCODE_0, scanCode=11, metaState=0, flags=0x8, repeatCount=0, eventTime=6536876, downTime=6536811, deviceId=0, source=0x301 } I/System.out( 1098): BaseActivity calling: /login/maskedPassword onResponseData: {"response":{"state":"A","authenticated":true},"msgId":"1344674218830418930","errorCode":0,"time":1351588394408,"errorDesc":""}

Page 21: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 22: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 23: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 24: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 25: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 26: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 27: Testowanie bezpieczeństwa aplikacji mobilnych

Logi, cache – skutki

● Warunki wykorzystania trudne do spełnienia– Kto może te logi czytać?– Jak długo są przetrzymywane?– Czy problem dotyczy tylko jednego feralnego builda?– Czy problem występuje na wszystkich wersjach OS?– Jakie dodatkowe warunki muszą być spełnione?– ...

● Ale to może nie mieć żadnego znaczenia w obliczu klęski wizerunkowej – np. Starbucks, styczeń 2014

Page 28: Testowanie bezpieczeństwa aplikacji mobilnych

RPCInna aplikacja na urządzeniu

Page 29: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction(); if (action...)

Page 30: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction(); if (action...)

Intent intent = new Intent();intent.setComponent (“MojReceiver”); sendBroadcast(intent);

Page 31: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction(); if (action...)

Intent intent = new Intent();intent.setComponent (“MojReceiver”); sendBroadcast(intent);

Nullpointer exceptionCRASH

Page 32: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction(); if (action...)

Intent intent = new Intent();intent.setComponent (“MojReceiver”); sendBroadcast(intent);

String action = intent.getAction();if (action != null ){

if(action...)

Nullpointer exceptionCRASH

Page 33: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction();if (action != null) ){

Uid = intent.getStringExtra(“android.intent.extra.UID”);

Page 34: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction();if (action != null) ){

Uid = intent.getStringExtra(“android.intent.extra.UID”);

Intent intent = new Intent (“AKUKU”);intent.setComponent (“MojReceiver”); intent.putExtra (“android.intent.extra.UID”, attackerUID);sendBroadcast(intent);

Page 35: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<receiver android:name =“MojReceiver”>

<intent -filter>

<action android:name = "android.intent.action.PACKAGE_ADDED"

String action = intent.getAction();if (action != null) ){

Uid = intent.getStringExtra(“android.intent.extra.UID”);

Intent intent = new Intent (“AKUKU”);intent.setComponent (“MojReceiver”); intent.putExtra (“android.intent.extra.UID”, attackerUID);sendBroadcast(intent);

String action = intent.getAction();if (action != null && action.equals (“PACKAGE_ADDED”) ){

Uid = intent.getStringExtra(“android.intent.extra.UID”);

Page 36: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<permission android:name ="com.dobreprogramy.permission"

android:protectionLevel = "signature" ...

<receiver android:name ="dobryReceiver" android:exported="true"

android:permission="com.dobreprogramy.permission">

...

</receiver>

Page 37: Testowanie bezpieczeństwa aplikacji mobilnych

BAD INTENTions<permission android:name ="com.dobreprogramy.permission"

android:protectionLevel = "signature" ...

<receiver android:name ="dobryReceiver" android:exported="true"

android:permission="com.dobreprogramy.permission">

...

</receiver>

<permission android:name ="com.dobreprogramy.permission" android:protectionLevel="normal" ...><uses-permission android:name ="com.dobreprogramy.permission"/>

Intruz może zarejestrować to samo wcześniej

Page 38: Testowanie bezpieczeństwa aplikacji mobilnych

Analiza/atak RPC

● Mnóstwo narzędzi– Drozer https

://www.mwrinfosecurity.com/products/drozer/– Android Hooker, comdroid, chex, epicc, iSEC intent

fuzzer/sniffer...● Ręcznie am broadcast -n com.aplikacja/com.aplikacja.BroadcastReceiver

am start -a android.intent.action.CALL -d tel://000-0000

Page 39: Testowanie bezpieczeństwa aplikacji mobilnych

Transmisja

Ataki na transmisję - podsłuch, słabości SSL

Intruz musi mieć dostęp do transmisji – pasywny (podsłuch), lub aktywny –aby modyfikować ruch

Page 40: Testowanie bezpieczeństwa aplikacji mobilnych

Przechwytywanie ruchu● Local proxy – co się dzieje „na łączu” (np. żądania HTTP)

– Burp: wersja darmowa na początek wystarczy

portswigger.net/burp– Fiddler – MS

www.telerik.com/fiddler– wiele innych

● Emulator przez proxy:emulator -avd emu -http-proxy 127.0.0.1:8080

www.telerik.com/fiddler/

Page 41: Testowanie bezpieczeństwa aplikacji mobilnych

SSL – wróćmy do podstaw

CA

Page 42: Testowanie bezpieczeństwa aplikacji mobilnych

Co zrobi klient?

● Jeśli ten sam certyfikat byłby podpisany innym CA?

[POWINIEN] wyświetlić ostrzeżenie, przerwać transmisję...

Zaakceptuje bez mrugnięcia.

CA nie jest w zaufanych

CA w zaufanych

Page 43: Testowanie bezpieczeństwa aplikacji mobilnych

Certyfikaty CA zaszyte w urządzeniach● Ćwiczenie: sprawdź jakie CA masz w swoim

telefonie● Np. iOS8 ma m.in. certyfikaty rządów:Chin: China Internet Network Information Center

Hong Kongu: Hongkong Post e-Cert.

Japonii: 3 CA

Holandii: 3 CA (PKIoverheid)

Taiwanu: Government Root Certification Authority

Turcji: Scientific and Technological Research Council of Turkey

USA: 5 CA, Department of Defense

Page 44: Testowanie bezpieczeństwa aplikacji mobilnych

SSL – „Man in the middle”

CA

?

Verisignwww.pewnafirma.pl

Verisignwww.pewnafirma.pl

Page 45: Testowanie bezpieczeństwa aplikacji mobilnych

Stosunkowo często...

sslcontext = SSLContext.getInstance("TLS");

atrustmanager = new TrustManager[1];

atrustmanager[0] = new EasyX509TrustManager(null);

sslcontext.init(null, atrustmanager, null);

Pusty TrustManager – akceptuje wszystkie certyfikaty

Page 46: Testowanie bezpieczeństwa aplikacji mobilnych

Przechwytywanie ruchu SSL

● Certyfikat CA Burp-a

Page 47: Testowanie bezpieczeństwa aplikacji mobilnych

Instalujemy w urządzeniu

● Aplikacja używa domyślnego truststore urządzenia– Android > 4 – w interfejsie– Wrzucamy na kartę SD (plik .crt)

adb push cacert.der /sdcard/cacert.crt

– „Zainstaluj z karty SD”

● Certyfikat zaszyty w aplikacji (pinning)– Podmieniamy w paczce aplikacji

Page 48: Testowanie bezpieczeństwa aplikacji mobilnych

API

API – błędy kontroli dostępu, logiczne, konfiguracji...

Page 49: Testowanie bezpieczeństwa aplikacji mobilnych

Mobile CAPTCHA

● Proces rejestracji, potwierdzanej SMS● CAPTCHA w celu ograniczenia masowego

nadużycia procesu (koszty SMS, przeciążenie systemu...)

● Należy kliknąć w odpowiedni obrazek (1 z 6)

Page 50: Testowanie bezpieczeństwa aplikacji mobilnych
Page 51: Testowanie bezpieczeństwa aplikacji mobilnych

Mobile CAPTCHA

● Pomysł chybiony już w założeniach– Prawdopodobieństwo trafienia „na ślepo” bardzo

wysokie● W implementacji jeszcze gorzej

– Każdy obrazek to inny statyczny plik, intruz może je zindeksować i ustalić w którym miejscu jest obrazek przedstawiający żądane słowo

Page 52: Testowanie bezpieczeństwa aplikacji mobilnych

REST API

fragment otrzymanej dokumentacji REST API

Page 53: Testowanie bezpieczeństwa aplikacji mobilnych

Historia rachunku

Page 54: Testowanie bezpieczeństwa aplikacji mobilnych

Żądanie HTTP po przechwyceniuGET /services/history/account/85101022350445200448009906 HTTP/1.1

SA-DeviceId: 940109f08ba56a89

SA-SessionId: 826175

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

GET /services/history/account/45101022350445200448005388 HTTP/1.1

SA-DeviceId: 940109f08ba56a89

SA-SessionId: 826175

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Podmiana nr rachunku – uzyskujemy cudze dane

Page 55: Testowanie bezpieczeństwa aplikacji mobilnych

Dane użytkownika

Użytkownik 1GET /services/user/profile HTTP/1.1

SA-DeviceId: d4c79a0fd994b1f8

SA-SessionId: 850071

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Page 56: Testowanie bezpieczeństwa aplikacji mobilnych

Dane użytkownika

Użytkownik 1GET /services/user/profile HTTP/1.1

SA-DeviceId: d4c79a0fd994b1f8

SA-SessionId: 850071

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

Użytkownik 2GET /services/user/profile HTTP/1.1

SA-DeviceId: 940109f08ba56a89

SA-SessionId: 850075

Accept: application/json

Host: acc

Connection: Keep-Alive

User-Agent: Apache-HttpClient/UNAVAILABLE (java 1.4)

DeviceId jedynym zabezpieczeniem

Page 57: Testowanie bezpieczeństwa aplikacji mobilnych

Historia pewnej aplikacji...

● Mnóstwo błędów kontroli dostępu● Po zgłoszeniu dostawcy:

„Kontrola dostępu w aplikacji jest, tylko na testowym środowisku wyłączona”

● Pomimo napiętych terminów włączyć się udało dopiero po kilku tygodniach ;)

Page 58: Testowanie bezpieczeństwa aplikacji mobilnych

Przechwytywanie ruchu – utrudnienie

Page 59: Testowanie bezpieczeństwa aplikacji mobilnych

Prawdopodobnie powstrzyma przypadkowych...

http://www.recreateweb.com.au/web-development/respond-2014-what-responsive-web-design-can-learn-from-accessibility-best-practice/

Page 60: Testowanie bezpieczeństwa aplikacji mobilnych

...oraz masowych intruzów

http://www.recreateweb.com.au/web-development/respond-2014-what-responsive-web-design-can-learn-from-accessibility-best-practice/

Page 61: Testowanie bezpieczeństwa aplikacji mobilnych

A Was?

#1 – żeby coś zaatakować trzeba zrozumieć jak to działa

https://www.flickr.com/photos/itspaulkelly/633298765

Page 62: Testowanie bezpieczeństwa aplikacji mobilnych

Zaszyfrowany ruch

Jak się dobrać do transmisji?

KLUCZ PUBLICZNY

LOSOWYKLUCZ SESJI

SESYJNY DO SERWERA

TRANSMISJA ZASZYFROWANA KLUCZEM SESJI

Page 63: Testowanie bezpieczeństwa aplikacji mobilnych

Drobne usprawnienie aplikacji – stały klucz w SMALI

new-array v8, v8, [B

fill-array-data v8, :array_5a

return-object v8

:array_5a

.array-data 1

0x44t

0x2bt

0x72t

(...)

Page 64: Testowanie bezpieczeństwa aplikacji mobilnych

Burp extension

Page 65: Testowanie bezpieczeństwa aplikacji mobilnych

Burp extension

Page 66: Testowanie bezpieczeństwa aplikacji mobilnych

Burp Extension

Page 67: Testowanie bezpieczeństwa aplikacji mobilnych

Burp Extension

Page 68: Testowanie bezpieczeństwa aplikacji mobilnych

Burp Extension

Page 69: Testowanie bezpieczeństwa aplikacji mobilnych

Architektura, środowisko

Page 70: Testowanie bezpieczeństwa aplikacji mobilnych

Znane podatności

Page 71: Testowanie bezpieczeństwa aplikacji mobilnych

Konsole administracyjne

Page 72: Testowanie bezpieczeństwa aplikacji mobilnych

Konsole administracyjne

Page 73: Testowanie bezpieczeństwa aplikacji mobilnych

Niektóre schwytane problemy REST● Błędy kontroli dostępu● Nieprawidłowa obsługa sesji● Błędy uwierzytelnienia i

autoryzacji● Błędy logiczne● SQL injection● Błędy architektury/konfiguracji● ...

https://www.flickr.com/photos/elycefeliz/6648603999

Page 74: Testowanie bezpieczeństwa aplikacji mobilnych

Część z ryzyk do ogarnięcia

Page 75: Testowanie bezpieczeństwa aplikacji mobilnych

OWASP Mobile Top 10

Page 76: Testowanie bezpieczeństwa aplikacji mobilnych

Czekamy na Was!

[email protected]

Darmowe konsultacje:

www.securing.pl/konsultacje

Pracuj z nami:http://www.securing.pl/pl/kariera.html