oauth2 and csrf attck
I'm currently working on oauth2 implementation and i wonder about CSRF attack.
I so very good explanation : in this scheme https://image.slidesharecdn.com/owasp-nulloauth2-160803124628/95/oauth-20-security-considerations-11-638.jpg?cb=1470228518 or this video https://www.youtube.com/watch?v=_xrhWLqX1j0 but i dont understand the goal.
At the end my account will have access to the attacker account, i cant get data from it but not the reverse. Am I right ? What is the benefit for the attacker to do this ?
Thank's for your answer,
oauth oauth-2.0 csrf
asked Nov 22 at 16:29
Mathieu
333
add a comment |
I'm currently working on oauth2 implementation and i wonder about CSRF attack.
I so very good explanation : in this scheme https://image.slidesharecdn.com/owasp-nulloauth2-160803124628/95/oauth-20-security-considerations-11-638.jpg?cb=1470228518 or this video https://www.youtube.com/watch?v=_xrhWLqX1j0 but i dont understand the goal.
At the end my account will have access to the attacker account, i cant get data from it but not the reverse. Am I right ? What is the benefit for the attacker to do this ?
Thank's for your answer,
oauth oauth-2.0 csrf
asked Nov 22 at 16:29
Mathieu
333
add a comment |
I'm currently working on oauth2 implementation and i wonder about CSRF attack.
I so very good explanation : in this scheme https://image.slidesharecdn.com/owasp-nulloauth2-160803124628/95/oauth-20-security-considerations-11-638.jpg?cb=1470228518 or this video https://www.youtube.com/watch?v=_xrhWLqX1j0 but i dont understand the goal.
At the end my account will have access to the attacker account, i cant get data from it but not the reverse. Am I right ? What is the benefit for the attacker to do this ?
Thank's for your answer,
oauth oauth-2.0 csrf
asked Nov 22 at 16:29
Mathieu
333
I'm currently working on oauth2 implementation and i wonder about CSRF attack.
I so very good explanation : in this scheme https://image.slidesharecdn.com/owasp-nulloauth2-160803124628/95/oauth-20-security-considerations-11-638.jpg?cb=1470228518 or this video https://www.youtube.com/watch?v=_xrhWLqX1j0 but i dont understand the goal.
At the end my account will have access to the attacker account, i cant get data from it but not the reverse. Am I right ? What is the benefit for the attacker to do this ?
Thank's for your answer,
oauth oauth-2.0 csrf
oauth oauth-2.0 csrf
asked Nov 22 at 16:29
Mathieu
333
asked Nov 22 at 16:29
Mathieu
333
asked Nov 22 at 16:29
Mathieu
333
asked Nov 22 at 16:29
Mathieu
333
asked Nov 22 at 16:29
Mathieu
333
333
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435040%2foauth2-and-csrf-attck%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
add a comment |
There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
add a comment |
There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
There are several other answers (ex:- this and this) explaining the background of state and how it avoid csrf.
Best thing is to refer what is given by specification creators. RFC6810 - OAuth 2.0 Threat Model and Security Considerations contains many threats and counter measurements for OAuth 2.0. In that Threat: CSRF Attack against redirect-uri gives a solid overview on the threat. Following is an extract,
An attacker could authorize an authorization "code" to
their own protected resources on an authorization server. He then
aborts the redirect flow back to the client on his device and tricks
the victim into executing the redirect back to the client. The
client receives the redirect, fetches the token(s) from the
authorization server, and associates the victim's client session with
the resources accessible using the token.
Now client has tokens which belongs to attacker. No, attacker won't be able to access anything that belongs to client in resource server. But if client perform a storing operation (ex :- Document create), this will be sent to malicious party. Now malicious party get access rights to those freshly created resource. This is highlighted as below,
The
effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's
resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's identity at
the external Identity Provider. In this way, the attacker could
easily access the victim's data at the client by logging in from
another device with his credentials at the external Identity
Provider.
So basically threat is associated with fresh data created at resource server.
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
edited Nov 23 at 8:47
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
answered Nov 23 at 8:08
Kavindu Dodanduwa
5,60611230
5,60611230
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53435040%2foauth2-and-csrf-attck%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
