Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my application first time I have given valid credentials and then login into application at that time i saved the response using burp time i have given wrong credentials and click login button,while clicking login button at that time i changed the response using burp tool.finally i have logged into my application.

if think it is risk then how can i give the severity of this risk?

please help me i am new this type testing.

share|improve this question

It is a little tricky to understand what you are asking. I think you are asking about how to rate the severity of an authentication replay attack.

The questions you need to ask are:

  • what is the risk to you, or your client, of an unauthenticated user accessing the data? If it wouldn't have any impact then it is probably low risk. If they could destroy databases, make payments or carry out destructive tasks then it is probably major.
  • are there other controls in place to detect their activities once logged in?
  • are the network and computer secured such that an attacker could not use a tool like burp in practice? If so, it is probably not as important.

The thing to remember is that it depends on the environment, client, application, usage, users etc.

share|improve this answer

If you want to protect against badguys stealing your user's sessions and protecting the data if they do.

  1. Use HTTPs that way the attacker has to man in the middle the victim and there is some warning in the form of a certificate error (which the user will probably ignore anyway)
  2. Determine how long a user normally will spend on your site and make an absolute timeout around that so if an attacker does grab an auth token they don't have continued access
  3. Make sure the framework you're using generates good random auth tokens so they can't be guessed
  4. Any super important actions such as changing a password or financial information should require them to enter their password again rather than rely on the auth token.
  5. Don't collect and store sensitive data if you don't absolutely need it!
  6. If you do have sensitive data then try really hard to never show it. If you need to show it only show part of it like the last 4 of a SSN rather than the full SSN.
  7. Make sure sensitive data is encrypted and passwords are salted and hashed in the database

There's more to it but I think those are the core items. If anyone has more please chime in!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.