Tamper Proffing server Response

[govardan_raj]

HI experts,

we have two level authentications to our portal Login.

ie. first level --> userid/ password

second leve l --> entering one time password .. that is recievied via sms.

now in the first level when i enter user name and valid pw and on click of login button , the server gives a Response1 (http server response)

now in the second level also when i enter OTP and click button Login , the server gives a Response2 (http server response)

when im logging in for the first time and capture these two responses , and next time if i replace the Response1 with Response2 , then im able to by pass the second level authentication .

Please suggest a solution for the same

Regards

Govardan Raj S

[mvoros]

Hi,

you seemed to have implemented some kind of two factor auth. You need to give us more details how you did this. Hod did you implement it? Do you have a custom logon module in portal? What do you mean by "capture these two responses".

Cheers,

Martin

[govardan_raj]

Hi martin,

yes we have implemented two factor auth.

we are using custom logon module.

here we have Burp Proxy tool to capture the request and response of the server.

What do you mean by "capture these two responses".

here when i press login button on entering user name and password , i get http server response

200  ok message.

and after 2 factor authentication , we get another http server response 200 ok message.

now when im logging in again , entering user name and password , here if i replace the  http server response with 2factor authentication response , im able to bypass the 2factore authentication...

Regards

Govardan Raj S

[mvoros]

Was it implemented by you or it's a third party product? It really depends on what is done when the first request is processed and the second request is processed. But it could be OK. When you authenticate against Java AS the system issues a logon ticket in form of cookie that is later used for re-authentication for the following requests. I assume that the second response contains a cookie. This cookie is valid for some limited time. So when you replay the second response you might be re-using that cookie? The problem with SAP SSO cookie is that you can't kill it on server side. There are different cookies used by ABAP AS that are binded to a session that can be killed on server side.

Cheers

[govardan_raj]

Hi Martin ,

here for verifying the OTP we are using a third party product ,

when the first request is processed we are just navigating from login jsp to enter OTP jsp , and when second request is processed , we are checking if the OTP is valid and if successfully verified at third party also , we navigate to the applications.

here how can we authenticate the server response ?

Regards

Govardan Raj S

[mvoros]

Is logon module written by you or by third party? I woudl suggest you to see what cookies are returned in requests one and two. I assume that the request two returns SSO cookie called MYSAPSSO2. This cookie is usually valid for 8 hours and is used for all other requests sent to portal. If you get access to it then you can use it for authentication.

Cheers

[govardan_raj]

Logon module is written by me, ill check over for cookie MYSAPSSO2.

Regards

Govardan Raj

[mvoros]

Ok, here is how I would write two factor auth.

1. Display a standard logon screen with fields for username and password

2. Check user name and password entered by user

3. If username/password are correct then do NOT authenticate user yet. Instead create a record in DB with the following fields: random ID, user name, code, validity (e.g. restrict to 5 minutes). Redirect user to another page and put random ID into URL plus send a SMS message to user.

4. On this second page display a form for a user to enter code sent to him.

5. If user enters a code then check it against a record in DB. If it's still valid then authenticate user and redirect him to original URL.

But again, if an attacker is able to capture SSO cookie issued by system after successful verification of code (second factor) then he can bypass two factor auth. Hence you really have to protect connection with TLS.

Cheers

[govardan_raj]

Hi martin and samuli ,

I found a solution for the above problem .

Assume the traverse should happen from

P1 -----R1------>P2-----R2----->P3-----R3----->P4-----R4----->P5 .

where Pn  is page and Rn is the Server Reponse as told earlier here when we navigate from P1 to P2 , the server response is R1 now if we replace that with R4 it is getting navigated to P5.

now every page as got its own name,

so when you navigate from P1 to P2 , use session to store a value i.e session.setattribute("", ""); , of type string , which is comibnation of pagename to which navigation should happen and session id, so here it is P2_sessionID,

In all the pages write code that when page is getting loaded that it should read value from the session,

now when P2 is getting loaded write a code to fetch the value from the session, so it should P2_sessionID, in case R1 is being replaced by server response R4 then you will navigate to P5 , now in P5 when loading , read value from session we get P2_session id , here P2 is the page that should have been loaded but P5 is getting loaded , so in P5 write a code to invalidate the session and logoff the user .

if any better standard approach exits please suggest , so that i could follow that.

Regards

Govardan

[Former Member]

I thought I would throw in my 2 cents since the original discussion thread was deleted from the wrong space rather than moving it here. As I wrote earlier, you are trying to accomplish something that SAML already provides. The only way to fight man in the middle attacks is to make sure that every request is properly authenticated. For a reference scenario based on SAML and RSA SecurID, see this document.

[govardan_raj]

hi samuli,

Thanks for you reply , ya the original thread was delete by moderators as they suggested it should be in security, hence i started this in new thread again.

Il go throught he doucment as suggested by you and get back soon.

Regards

Govardan