Is a component only launched from a quick action safe from CSRF?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I've got a component that is launched from a quick action and on init preforms some DML and redirects the user. It only implements these three interfaces and is not referenced anywhere else in the application: force:LightningQuickAction
, force:hasRecordId
, force:hasSObjectName
Would I be able to document this as a false positive for CSRF with the justification that this component does not have a URL?
lightning-components lightning security-review csrf
add a comment |Â
up vote
2
down vote
favorite
I've got a component that is launched from a quick action and on init preforms some DML and redirects the user. It only implements these three interfaces and is not referenced anywhere else in the application: force:LightningQuickAction
, force:hasRecordId
, force:hasSObjectName
Would I be able to document this as a false positive for CSRF with the justification that this component does not have a URL?
lightning-components lightning security-review csrf
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I've got a component that is launched from a quick action and on init preforms some DML and redirects the user. It only implements these three interfaces and is not referenced anywhere else in the application: force:LightningQuickAction
, force:hasRecordId
, force:hasSObjectName
Would I be able to document this as a false positive for CSRF with the justification that this component does not have a URL?
lightning-components lightning security-review csrf
I've got a component that is launched from a quick action and on init preforms some DML and redirects the user. It only implements these three interfaces and is not referenced anywhere else in the application: force:LightningQuickAction
, force:hasRecordId
, force:hasSObjectName
Would I be able to document this as a false positive for CSRF with the justification that this component does not have a URL?
lightning-components lightning security-review csrf
lightning-components lightning security-review csrf
edited 40 mins ago
codeyinthecloud
1,556217
1,556217
asked 1 hour ago
bafuda
468414
468414
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago
add a comment |Â
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
YES and NO, It can be little tricky! Even though the dml is happening on component load but which is still a click by a human intervention(because its a quick action) this would be a hard one to determine.
CSRF : In order to prevent CSRF attacks, do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
(
doInit: function(cmp)
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
,
handleClick: function(cmp, event)
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
)
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
Developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated
add a comment |Â
up vote
1
down vote
Adding few pointers to what codeyInTheCloud has said.
It's a good practice to not do DML in onLoad of page in VF and init method of lightning, but if there is a strong business use case and there is no way out then it is acceptable.
eg: You have to audit when a record is opened by a user, and how many times, then, in that case, we use a VF page or lightning component and do a dml on page load. There is always a risk with this but can be still mitigated if certain things are followed.
Avoid Dynamic SOQL in Apex controller (https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_security_tips_soql_injection.htm) , if needed atleast sanitize the input received
If doing delete or update of critical data, always ask for confirmation from end user, using modal or page messages.
Following these practices and giving a proper explanation to security team, you can get the app reviewed without hassels.
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
YES and NO, It can be little tricky! Even though the dml is happening on component load but which is still a click by a human intervention(because its a quick action) this would be a hard one to determine.
CSRF : In order to prevent CSRF attacks, do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
(
doInit: function(cmp)
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
,
handleClick: function(cmp, event)
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
)
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
Developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated
add a comment |Â
up vote
2
down vote
accepted
YES and NO, It can be little tricky! Even though the dml is happening on component load but which is still a click by a human intervention(because its a quick action) this would be a hard one to determine.
CSRF : In order to prevent CSRF attacks, do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
(
doInit: function(cmp)
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
,
handleClick: function(cmp, event)
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
)
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
Developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
YES and NO, It can be little tricky! Even though the dml is happening on component load but which is still a click by a human intervention(because its a quick action) this would be a hard one to determine.
CSRF : In order to prevent CSRF attacks, do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
(
doInit: function(cmp)
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
,
handleClick: function(cmp, event)
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
)
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
Developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated
YES and NO, It can be little tricky! Even though the dml is happening on component load but which is still a click by a human intervention(because its a quick action) this would be a hard one to determine.
CSRF : In order to prevent CSRF attacks, do not invoke any server-side controller method that performs a DML operation automatically as the result of a page load. Specifically, do not invoke server-side DML controller method as onInit handlers, or afterRender handlers (if rendering is performed automatically on page load).
(
doInit: function(cmp)
var action = cmp.get("c.updateField"); //vulnerable to CSRF
[...]
$A.enqueueAction(action);
,
handleClick: function(cmp, event)
var action = cmp.get("c.updateField"); //not vulnerable to CSRF
[...]
$A.enqueueAction(action);
)
The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.
Developers should be cautious about writing pages that take action based upon a user-supplied parameter like the id variable in the preceding example. A possible work-around is to insert an intermediate confirmation page before taking the action, to make sure the user intended to call the page. Other suggestions include shortening the idle session timeout for the organization and educating users to log out of their active session and not use their browser to visit other sites while authenticated
edited 59 mins ago
answered 1 hour ago
codeyinthecloud
1,556217
1,556217
add a comment |Â
add a comment |Â
up vote
1
down vote
Adding few pointers to what codeyInTheCloud has said.
It's a good practice to not do DML in onLoad of page in VF and init method of lightning, but if there is a strong business use case and there is no way out then it is acceptable.
eg: You have to audit when a record is opened by a user, and how many times, then, in that case, we use a VF page or lightning component and do a dml on page load. There is always a risk with this but can be still mitigated if certain things are followed.
Avoid Dynamic SOQL in Apex controller (https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_security_tips_soql_injection.htm) , if needed atleast sanitize the input received
If doing delete or update of critical data, always ask for confirmation from end user, using modal or page messages.
Following these practices and giving a proper explanation to security team, you can get the app reviewed without hassels.
add a comment |Â
up vote
1
down vote
Adding few pointers to what codeyInTheCloud has said.
It's a good practice to not do DML in onLoad of page in VF and init method of lightning, but if there is a strong business use case and there is no way out then it is acceptable.
eg: You have to audit when a record is opened by a user, and how many times, then, in that case, we use a VF page or lightning component and do a dml on page load. There is always a risk with this but can be still mitigated if certain things are followed.
Avoid Dynamic SOQL in Apex controller (https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_security_tips_soql_injection.htm) , if needed atleast sanitize the input received
If doing delete or update of critical data, always ask for confirmation from end user, using modal or page messages.
Following these practices and giving a proper explanation to security team, you can get the app reviewed without hassels.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Adding few pointers to what codeyInTheCloud has said.
It's a good practice to not do DML in onLoad of page in VF and init method of lightning, but if there is a strong business use case and there is no way out then it is acceptable.
eg: You have to audit when a record is opened by a user, and how many times, then, in that case, we use a VF page or lightning component and do a dml on page load. There is always a risk with this but can be still mitigated if certain things are followed.
Avoid Dynamic SOQL in Apex controller (https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_security_tips_soql_injection.htm) , if needed atleast sanitize the input received
If doing delete or update of critical data, always ask for confirmation from end user, using modal or page messages.
Following these practices and giving a proper explanation to security team, you can get the app reviewed without hassels.
Adding few pointers to what codeyInTheCloud has said.
It's a good practice to not do DML in onLoad of page in VF and init method of lightning, but if there is a strong business use case and there is no way out then it is acceptable.
eg: You have to audit when a record is opened by a user, and how many times, then, in that case, we use a VF page or lightning component and do a dml on page load. There is always a risk with this but can be still mitigated if certain things are followed.
Avoid Dynamic SOQL in Apex controller (https://developer.salesforce.com/docs/atlas.en-us.pages.meta/pages/pages_security_tips_soql_injection.htm) , if needed atleast sanitize the input received
If doing delete or update of critical data, always ask for confirmation from end user, using modal or page messages.
Following these practices and giving a proper explanation to security team, you can get the app reviewed without hassels.
answered 40 mins ago
Pranay Jaiswal
10k31949
10k31949
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f237935%2fis-a-component-only-launched-from-a-quick-action-safe-from-csrf%23new-answer', 'question_page');
);
Post as a guest
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
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
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
Would it be possible to explain a little more on nature of the quick action and why is the dml needed?
â codeyinthecloud
1 hour ago
The resource that the user is redirected to expects a record to exist in the database. So this component creates the record and redirects to that resource. It's a bad design but if it safe then I'd rather not spend the time fixing it right now. Thanks for the help!
â bafuda
18 mins ago
Before inserting if you can confirm with user it wnt be breaking CSRF then.
â Pranay Jaiswal
15 mins ago
honestly Successfully performing a CSRF attack is not trivial. It requires the targeted user to visit the attack page while authenticated with the targeted service, which often requires coordinated deception on the part of the attacker (this is mostly commonly seen in phishing campaigns). Just show a confirmation before redirecting can help for now! more here
â codeyinthecloud
14 mins ago