1. SEA-SURFING IN ASP.NET MVC
BARTOSZ LENAR

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. FIDDLER
responses
requests

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. COOKIES
 exist in headers as another key-value pair "with parameters"
 cookies consist of
 name
 value
 domain & path
 expiration date
 restrictions (security)

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. HTTP REQUESTS AND COOKIES

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. 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. 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. 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. 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. 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. LET’S TRYTO GET THE ADMIN’S SECRET

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. 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. LET’S TRYTO DO THE ADMIN’S JOB

18. BUILDING THE FIREWALL
 how browser works:
 attacker is able to send cookies with the request …
 … but is not able to see them!

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. 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. 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. DO THE TRICK IN ASP.NET MVC

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. 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. SINGLE PAGE APPS - PROBLEMS
 forms are pre-generated
 which form is going to be triggered next?

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. API WRAPPER – SERVER SIDE
 keep tokens in cache/database
 nosql
 custom ValidateAntiForgeryTokenAttribute
 validates token from cookie and header
 updating token if necessary

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. 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