Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

QA Lab: тестирование ПО. Владимир Гарбуз: "Application Security 101"

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Nächste SlideShare
Selenium web driver
Selenium web driver
Wird geladen in …3
×

Hier ansehen

1 von 20 Anzeige

QA Lab: тестирование ПО. Владимир Гарбуз: "Application Security 101"

Herunterladen, um offline zu lesen

05.12.12 QA Lab: тестирование программного обеспечения.
Upcoming events: goo.gl/I2gJ4H

В этом докладе мы рассмотрим самые распространенные проблемы в безопасности приложений и то, как вы можете их найти в ваших проектах. Мы коснемся инструментария взломщика веб-приложений и основных уязвимостей - XSS, SQL инъекций, XXE, аутентификации, авторизации, управления сессиями, атак отказа в обслуживании, и так далее.

05.12.12 QA Lab: тестирование программного обеспечения.
Upcoming events: goo.gl/I2gJ4H

В этом докладе мы рассмотрим самые распространенные проблемы в безопасности приложений и то, как вы можете их найти в ваших проектах. Мы коснемся инструментария взломщика веб-приложений и основных уязвимостей - XSS, SQL инъекций, XXE, аутентификации, авторизации, управления сессиями, атак отказа в обслуживании, и так далее.

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Ähnlich wie QA Lab: тестирование ПО. Владимир Гарбуз: "Application Security 101" (20)

Anzeige

Weitere von GeeksLab Odessa (20)

Aktuellste (20)

Anzeige

QA Lab: тестирование ПО. Владимир Гарбуз: "Application Security 101"

  1. 1. APPSEC 101 BREAK STUFF LIKE A PRO! WELL, ALSMOST…  Vladimir Garbuz
  2. 2. Contents  AppSec testing tools  Testing stages  Mapping application’s content  Input-based vulnerabilities  Denial of Service  Client-side controls
  3. 3. AppSec testing tools  the Swiss Army Knife of AppSec – Fiddler  not just a proxy  inspect HTTP and HTTPS! (best served in RAW)  modify and replay  intercept mid-air  setup reverse proxy mode  get request stats  set filters  do text encoding  scripting in C#
  4. 4. AppSec testing tools  WireShark – when Fiddler doesn’t cut it  only passive traffic monitoring  sees everything!  your browser’s developer console  socket programming in any language, e.g. Python   hacker’s mindset
  5. 5. Mapping application’s content  read the feature specs  monitor HTTP traffic for all user data entry points  look at interface differences for different user roles  record a request such controls send for users who can use them and replay them with user sessions that can’t  discover hidden content  ViewDocument.jsp  Delete, Upload, Edit, Create, etc.  lookout for direct server file access (filename
  6. 6. Input vulnerabilities
  7. 7. Input vulnerabilities: basic checks  check if server correctly handles unexpected data  negative indexes and values  overly large integers  zero-bytes  look for differences in processing of directly submitted values AND when parsed from a user uploaded or controlled file  relates to ALL input-based vulnerabilities!
  8. 8. Input vulnerabilities: SQL injections  use DB server management software and profiler  submit ‘ or “ in request, not only “Edit” operations!  SQLi can be anywhere where DB is accessed based on user data, in any way!  monitor for server errors AND the DB log/profiler!  broken SQL query in DB log, error, etc?.. REPORT!
  9. 9. Input vulnerabilities: XSS injections  general principle – lack of input encoding  user submitted data is unmodified in HTML page  from Google XSS guide: "A good test string is  >'>"><img src=x onerror=alert(0)  generally, raise an ALARM for any of the following 5:  < > & " ‘  within HTML actions and JavaScript code, additionally  n r ’ ” uXXXX  sometimes escaping won’t help
  10. 10. Input vulnerabilities: XSS injections  reflected XSS  when a part of URL is reflected back in HTML page  DON’T forget to URL encode special characters! e.g.:  http://url.com/1.jsp?param=%3E%3Cscript%3Ealert (1)%3C%2Fscript%3E  stored XSS  a malicious string is added to the server once and displayed as a part of a page to everyone viewing it  from POST body, HTTP header, uploaded file, HTML based server log, etc… MANY vectors!
  11. 11. Input vulnerabilities: XSS injections  DOM XSS  caused by unsafe JS during runtime inside the browser  same principles apply (at this low level)  monitor for special chars appearing in resulting HTML!  example: http://url.com/page.jsp?param=value#section1%3E %3Cscript%3Ealert(1)%3C%2Fscript%3E
  12. 12. OK, that’s enough, I’m leaving!
  13. 13. Input vulns: HTTP header injection  for each response header where user data appears  try inserting carriage-return and line-feed symbols  the actual symbols! “0d” and “0a” in hex  if they are returned in server response header unmodified  ALARM! malicious server headers can be forged or HTTP split!  Example evil URL: http://url.com/page.jsp?contentType=text/html%0d%0aE vilHeader%3A%20blabla  Example vulnerable server response: HTTP/1.1 200 OK Content-Type: text/html EvilHeader: blabla
  14. 14. Input vulns: XML injections - XXE  XML External Entities <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/shadow" > ] > <username>&xxe;</username><password>………… …  if no error or file is retruned by server – ALARM!  if gives an error, but it disappears after you remove embedded entity and leave only declaration, ALARM!
  15. 15. Input vulnerabilities
  16. 16. Input vulns: Open redirection  if the URL data specifies a redirection target  try modifying or adding the redirection domain, e.g. in  http://url.com/qcbin/authentication-point/web-ui- login.jsp?redirect-url=%2Fui%2F  after that, trigger an event that causes redirection, e.g. login  if it redirects to a different domain, ALARM!
  17. 17. Denial of Service
  18. 18. Denial of Service  check if server correctly handles unexpected data  zero-bytes in input  XML “billion laughs” attack or XXE of a huge file (/dev/random or c:pagefile)  unpacking large low entropy data  regex, globbing and other text processing functionality  asynchronous/heavy functionality invocation  API request flooding  slow HTTP - thread/socket exhaustion
  19. 19. XML Billion laughs attack - DoS  Recursive “billion laughs” attack <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <username>&lol9;</username><password>……………
  20. 20. Questions and Discussion Email: vladimir.garbuz@owasp.org Skype: vigarbuz

×