Security in Oracle ADF- CSRF/XSS

[Vinay Kumar]

Hi All,

 

I need information on how to deal with CSRF attack and XSS problem in ADF/ Webcenter application. I gone through the White paper by Frank Nimphius.

What we should do to protect application from these attacks.

 

According to white paper

Client token – Using client tokens, the view state is saved on the server, in the user session, and identified by the client only by a token. This is the default and recommended state saving method used in ADF applications. The tokens are encrypted using the MyFaces Trinidad state manager by for each view. It is recommended that you keep the default setting.

 

1)        So we should keep the default setting. Is that enough? Or do we need to do something more?

2)        Same question for XSS too. How to handle this?

3)        Is there any security analysis tool by which we can test our application for this? - I am aware of one tool zap attack proxy(ZAP). Is there some more better tool ? May be its good to share your experience here.

 

 

 

Thanks With Regards

Vinay Kumar

[Blake Sullivan]

On Jun 1, 2015, at 1:19 AM, Vinay Kumar <mail2v...@gmail.com> wrote:

Hi All,

 

I need information on how to deal with CSRF attack and XSS problem in ADF/ Webcenter application. I gone through the White paper by Frank Nimphius.

What we should do to protect application from these attacks.

 

According to white paper

Client token – Using client tokens, the view state is saved on the server, in the user session, and identified by the client only by a token. This is the default and recommended state saving method used in ADF applications. The tokens are encrypted using the MyFaces Trinidad state manager by for each view. It is recommended that you keep the default setting.

 

1)        So we should keep the default setting. Is that enough? Or do we need to do something more?

Both storing all of the state on the client and using the token are secure.  The reason for choosing one or the other is about performance tradeoffs rather than security.  I would use client state saving for my login page (if it is written using ADF) and token state saving for the rest of my pages.

2)        Same question for XSS too. How to handle this?

ADF Faces should take care of this for all of the output that it is generating on your behalf.  ADF Faces is HTML escaping and URL encoding the output for you.  There are two exceptions:

1) <af:outputText> with escape=false (true is the default).

2) <af:richTextEditor> if the content that you initially provide already contains an XSS attack.  While the richTextEditor sanitizes that user’s input, it assumes that the content you initially provide is already safe

If you are writing content to the output directly to the response’s Writer, you are on your own.  If you write to the appropriate  ResponseWriter methods, you should be fine.

3)        Is there any security analysis tool by which we can test our application for this? - I am aware of one tool zap attack proxy(ZAP). Is there some more better tool ? May be its good to share your experience here.

There are plenty of tools for attempting XSS attacks.  These tools are good for the cases where the attack actually succeeds.  Where they fall down is that the spew a large number of warnings for cases that in some cases could be a problem but in fact are not.

For anything other than a bare bones CSRF attack, you need somebody actually looking at the wire protocol in order to try and crack it.  The person needs to understand the limitations on the attacker performing the CSRF attack however.  We have had customers report a CSRF attack after their consultant manually copied the secret token(s) from the real POST into the attacker’s POST.

— Blake Sullivan

 

 

 

Thanks With Regards

Vinay Kumar

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.