Man in Middle Attack successful in MVC High Level APIs

Hello Team,

I have been using Fiddler to try some Man in the Middle attacks, by simply capturing some GET/POST requests in Fiddler and then replaying them after a Logout at the browser and I am still getting a HTTP 200 response back. Please check and let me know. I am evaluating the ComponentSpace software for using in a secure application, hence testing some basic security stuff and currently this problem is looking grave to me.

Here are the steps to replicate the particular problem, I am looking at:
1) Setup and Publish MvcExampleIdentityProvider and MvcExampleServiceProvider in IIS 7.5 and ensure that both IdP and SP initated login logout works.
2) Clear the browser cache IE / Mozilla / Chrome (whichever u want to use)
3) Start Fiddler 4
4) Using the browser, Go to http://localhost/MvcExampleIdentityProvider and sign in.
5) Once inside IdP, click on ‘SSO to the Service Provider’ i.e. go to the MvcExampleServiceProvider.
6) Once at the MvcExampleServiceProvider homepage, go to fiddler and earmark the particular GET request that got created so as to go the MvcExampleServiceProvider home page. It looks something like this:

GET http://localhost/MvcExampleServiceProvider/ HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://localhost/MvcExampleIdentityProvider/Home/SingleSignOn
Cookie: __RequestVerificationToken_L012Y0V4YW1wbGVJZGVudGl0eVByb3ZpZGVy0=heFR3OKh80Ki-kMSTsFH6DH_A5T0HJMuf1QHZAFU2Gv7sXa7QDj1S4I-9_8QQnBBC-J8ZKOdaMTUdESD5XvdZInWFIPD9FAHMkyMagQEMamQ0id8SXo_uFIV1mMopcZ2qiws0UgZsR1fbfSbVLOQrg2; MvcExampleIdentityProvider=30E87030FC408A5727D779DA042275FF7A67FC91FB66621FB94D1DB6FF62E5ECF8B9F849AD34C6FF98A9CA628688B7207AADF8F483625E0A67F19BD968741E18BD46469C7E03493A26CC602C849655402F79C89AF4F9122152A347458A8BED2C2743C8D8B6CFAA7D55D9BC73626D0A92AA20430DC6EFA4CAFFE28C06D28399D2505B97A95DA6481965E3EEB5458C0F65; ASP.NET_SessionId=4qvv2tuodpuo4zgw41b5ugvy; MvcExampleServiceProvider=E67F338DEAC314A2911E0C4D5A36BAC510FDCB88569F9758F0D1E05CC9B645CA1FE4B3E8A2B331E6D02728A07FBC7683121973259FC7D51E590823C133DE9624E1EFDD6949ECA69FF9FC117B3F5D46A4CEBF22C96CA044CF44B1D5D47B89A24E236264510EC85A771D2453B137A9B6E5E909B2C52A3C980F80C035C7BAC26CAC19E05C59FA4F02D599396D187EEFB8A1
Connection: keep-alive

7) Now, Logout at the SP using the browser and try to access the homepage again using the browser. Things work as expected and the user is challenged to enter the credentials.

8) BUT, if you go back to Fiddler and replay the earlier request to access the homepage of MvcExampleServiceProvider, the server does return the homepage content in the response, which SHOULD NOT happen. My understanding is that the captured request in Fiddler is from a user session that is no longer alive and if such a request is made again (using the same cookies), the server should be able to detect it and challenge the user.

NOTE: I have tried to attach the debugger in Visual Studio and checked that the replayed request indeed hits the action method of HomeController in the MvcExampleServiceProvider and returns the expected View.

Please check and confirm if this is the case and advise further. Unfortunately, I will have to park the things until then.

Thanks and regards

I don’t believe this is related to the SAML SSO process or our component. Instead it's IIS or ASP.NET related.

For example, if I do the following, I can reproduce the issue.

1. Log into http://localhost/MvcExampleIdentityProvider.
2. Logout from MvcExampleIdentityProvider (ie no SSO).
3. Replay the GET generated after login and before logout.

This sequence doesn't involve SAML SSO or any calls into our API.

I will look into this further to provide more information.