2

I have 2 app. First app (A) has client side (HTML) and server side (RUBY, PHP or something else). Second app (B) is an API. Everything is through https. Consider this scenario:

  1. A user type email and password in login box (App A, client side) and click "ok"
  2. App A (server side) checks CSRF token and send email and password to the API (App B) using HTTP credential specific for the API (only known server side)
  3. App B checks API credentials then checks user credentials (email and password)
  4. App B answers everything is ok to App A (server side)
  5. App A create a session for user, he can know use the application. Sometimes App A (server side) calls App B to ask something.

So is it secure enough ? Is it stupid ? Is it an acceptable method ?

Improve this question

1 Answer 1

Reset to default
4

It does not look bad. As an attacker, I would try to forge a valid request #2 to AppB directly, to see what happens. But if server side credentials are employed, as long as they are not weak, I should not succeed.

Some potential problems could be

  1. Bruteforcing - if it is highly secure or high traffic you may want to consider a captcha or any other verification code to prevent bruteforcing for both #1 and #2. Usually you don't display the captcha/verification for the first 5-10 logins, then you start asking people to behave like a human
  2. #3 and #4 - Ensure the is no way to "check" if that user is either registered or not to your user pool and (more important) if that password is valid or not. Information Leakage or anything similar could help an attacker to enumerate users or to know if an email (your login) is in your database, that is the starting of any social engineering attack.
  3. Replay attacks: is it possible for anyone intercepting a #2 request to reply to the server? I think this is false as you use HTTPs.
  4. #2 session time - how long does a session between AppA and AppB lasts? Usually s2s (system 2 system) channels have no session (i.e. AppA sends credentials all the time) or an infinite session (AppA sets the sessionID the first time, and it will last forever). In the second case, be sure session ids are not re-usable, at least. A session should never last more than a week, roughly.
  5. SSRF & similar: a fancy new item in our pentesting checklist. Nothing really special here, but ensure nobody can use AppA to make requests to AppB - for example, if in #5 the things asked to AppB can be controlled by the user, that is a concern, sanitize the input user.
  6. Fixed packets: if you have very small HTTPs requests that are more or less the same every time (#2 is a good target for this) they could be under the big umbrella of HTTPs attacks like CRIME and BREACH. Anyway this is a complex topic, I am just mentioning the possibility but, for those to be applicable, there are lots of things to be considered.
  7. Server side credentials to AppB - update of the password: ask yourself how hard is to change it if AppA configuration file with them is stolen? If the answer is "hardly impossible", it is a criticality. You should consider change such password every 3-6-12 months.

I see nothing critical in this description, in the end.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks ! This answer is perfectly clear and complete (from my perspective)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.