Sea surfing in asp.net mvc

597 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
597
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sea surfing in asp.net mvc

  1. 1. SEA-SURFING IN ASP.NET MVC BARTOSZ LENAR
  2. 2. THE PLAN BASICS  http requests  authentication  cookies  session SEA-SURFING  unfixable bug  hacking the system  csrf attack  token-based defence SPA  problems  server-side layer  client-side layer
  3. 3. FIDDLER responses requests
  4. 4. HTTP REQUEST  Method  Version  Host  Rest as key-value pairs:  Accept  Cache-control  …  BODY RESPONSE  Status dode  Version  Date  Rest as key-value pairs:  Content-type  Content-length  …  BODY
  5. 5. COOKIES  exist in headers as another key-value pair "with parameters"  cookies consist of  name  value  domain & path  expiration date  restrictions (security)
  6. 6. COOKIES SCENARIO 2. responds with cookie visited: true 1. sends request to example.org 4. sends request to example.org with visited:true cookie in headers 3. saves visited:true for example.org 5. knows that client visited this page earlier
  7. 7. HTTP REQUESTS AND COOKIES
  8. 8. WEB AUTHENTICATION  authentication system  authorize once at the beginning  use the system all the time  but http protocol is stateless!  every request is independent  how to simulate the states?  how to identify request from the specific user?
  9. 9. STATES SCENARIO 2. generates über-random identifier 1. sends first request to example.org 5. sends next request to example.org with UserId: QB32SDXC8 cookie in headers 4. saves UserId:QB32S… for example.org 3. sends it back in cookie UserId: QB32SDXC8
  10. 10. SESSION  so far: server is able to distinguish users  session: server-side bag for user data  key: previously generated identifier stored in cookie  like QB32SDXC8  value: yet another dictionary  user-specific data like name, address, etc.  security and access data like roles, privileges, etc.  forms
  11. 11. HACK THE SYSTEM  do we want to be an authorized user?  no! we want to act like one!  to hack the system = to "steal" someone’s session  maybe "someone” is:  facebook user – we have all his private data, photos, etc.  bank user – we know how much money he has  …  admin – we can do anything
  12. 12. SESSION HIJACKING  system/browser backdoor  steal the cookie from memory  xss  sidejacking  main-in-the middle  fixation  send user url with session id: http://example.org/?&sessionId=QB32SDXC8  wait for the user to log in  riding – our topic
  13. 13. THE ROADTO SESSION RIDING  we want to download data stored under http://example.org/admin/secret  let’s think:  authentication & authorization is based on session  session is based on cookies  cookies are being sent to example.org with every request  how about we prepare a website that sends request to the specified path?
  14. 14. LET’S TRYTO GET THE ADMIN’S SECRET
  15. 15. LET’S TRYTO GET THE ADMIN’S SECRET  what actually happened? 1. browser downloads the entire DOM tree 2. img node is being located 3. browser automatically sends GET request to download the image  but… there is no image at the end  nevertheless, browser attached all cookies dedicated to example.org <img src="http://example.org/admin/secret" />
  16. 16. LET’S TRYTO DO THE ADMIN’S JOB  GET shouldn’t change anything  http://example.org/admin/delete-user/?&username=admin  you’re doing itWRONG!  let’s mess up with POST / DELETE / PUT …
  17. 17. LET’S TRYTO DO THE ADMIN’S JOB
  18. 18. BUILDING THE FIREWALL  how browser works:  attacker is able to send cookies with the request …  … but is not able to see them!
  19. 19. ANTI-FORGERY TOKEN – HOW IT’S MADE 2. generates über-random identifier: J723SDA 1. sends request to example.org 3. sends it back inside the form and in the cookie AntiForgeryToken= J723SDA <input name="_token" type="hidden" value="J723SDA" />
  20. 20. ANTI-FORGERY TOKEN – HOW IT WORKS 1. sends request to example.org containing: • cookie with token: J723SDA • form value with token: J723SDA 2. validates the request: • token in cookie is present? true • token in form is present? true • do they match each other? true all true? it’s valid!
  21. 21. ANTI-FORGERY TOKEN – HOW IT SECURES 1. sends request to example.org containing: • cookie with token: J723SDA • form value with token: ?????????? 2. validates the request: • token in cookie is present? true • token in form is present? false • do they match each other? false all true? no! respond with 403 Forbidden
  22. 22. DO THE TRICK IN ASP.NET MVC
  23. 23. EVEN MORE SECURE  create a keyword based on:  action-specific and user-specific data  application, server, etc.  our keyword: "BARTEK"  hash the keyword: (0BDE667AA88E8832B61BF68C0D4E34A4) and split it:  0BDE667AA88E8832 goes into cookie  B61BF68C0D4E34A4 goes into form  on request, compute the keyword once again and validate the tokens
  24. 24. PROBLEMS  strongly relies on browser security  doesn’t work with GET requests  is it a problem in pure, REST service?  to disable cookies = to disable all communication  site vulnerable to XSS = we’re doomed
  25. 25. SINGLE PAGE APPS - PROBLEMS  forms are pre-generated  which form is going to be triggered next?
  26. 26. API WRAPPER – CLIENT SIDE  write wrapper for all ajax communication (GET, POST, PUT, DELETE)  requestSettings contains method, data, etc. ApiWrapper.prototype._SendRequest = function (requestSettings) { var self = this; requestSettings.headers["Token"] = self.Token; return $.ajax(requestSettings).always(function (arg1, textStatus, arg2) { jqXHR = (textStatus !== "success") ? arg1 : arg2; self.Token = jqXHR.getResponseHeader("Token"); document.cookie = "Token=" + self.TokenId + ";"; }); };
  27. 27. API WRAPPER – SERVER SIDE  keep tokens in cache/database  nosql  custom ValidateAntiForgeryTokenAttribute  validates token from cookie and header  updating token if necessary
  28. 28. API WRAPPER - USAGE  write wrapper for all ajax communication (GET, POST, PUT, DELETE)  return jqXHR from all functions api.Get('customers/' + customerId) .success(function (data) { self.Customer(data); }); api.Post('customers/' + customerId, editedData) .success(function () { message.ReportSuccess(); });
  29. 29. SEA-SURFING IN ASP.NET MVC QUESTIONS-SURFING  Fiddler: http://www.telerik.com/fiddler  Icons: http://www.visualpharm.com/ BARTOSZ LENAR bartoszlenar@gmail.com @bartoszlenar

×