Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

how to test cross-site scripting

Avatar

Level 4

Reposted as I accidently accepted the answer as accepted. 

 

I am using AEM 6.2.0.SP1-CFP19 . There is two vulnerabilities 1) Stored cross-site scripting and 2)Cross-site scripting. Anyone can guide how to check whether these two vulnerabilities have in myAEM?

 

 

ariesyinn_0-1620644583538.jpeg

I have added this in dispatcher level. Does it means the above fixes are solved?

ariesyinn_1-1620644694866.png

 

 

 

Thanks.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi @ariesyinn!

As already pointed out in your other thread, AFAIK there is no public information available on the exact nature of the two mentioned specific vulnerabilities. So unfortunately I don't see any way to reproduce the attack vectors and to directly verify if your AEM environment is still vulnerable for these exact issues. While you could test your application for some kind of XSS, this would still not give you any insights for these two specific vulnerabilities. XSS is a very broad field. I tried to find some more details about the nature of the vulnerabilities by their CVEs (as you probably did as well) but was unable to find any public source for it.

 

I've already outlined how to verify the version (incl. SP and CFP) that is installed on your AEM instance. That's one first and strong indicator that your environment should no longer be vulnerable to these two specific attack vectors. However, in IT security there is no way to guarantee a 100% secure system.

 

The rewrite rules that you shared from your dispatcher configuration provide some level of protection against certain XSS attacks. However, the field of XSS is very wide and there may still be other attack vectors that could possibly get past these simple rewriting rules. (Please note: while mod_rewrite can help to provide a certain level of basic protection, it is not a dedicated security tool.)

 

If you have enhanced security requirements (as often seen for customers from e. g. the financial sector), I recommend to:

  • Follow Adobes AEM Security Checklist
  • Follow Adobes Dispatcher Security Checklist
  • Follow recommended best practices during the development cycle as pointed out in these Security Considerations
  • Keep your overall software stack as up-to-date as possible. This does not only mean AEM but also your operating system, your Java runtime (JRE), 3rd party libraries that you are using, etc.
    In this context I would also recommend to evaluate if you want to upgrade AEM to a more recent version (6.5 for on-premise). According to Adobes end of life matrix, AEM 6.2 has run out of core support two years ago and even extended support ended last month (April 2021). So there will be no additional updates from Adobe for your specific version of AEM. If you really care about security, running an unsupported AEM version is probably one of the bigger security concerns you should look at. The very least that I would recommend is to upgrade to the latest available CFP for AEM 6.2 (SP1-CFP20) which has been released almost two years ago.
  • Evaluate some kind of Web Application Firewall (WAF).
    A popular choice I've seen in projects is mod_security with the OWASP Core Rule Set (CRS). The rule set contains protection against a wide range of attack vectors, including XSS. It's not AEM-specific but a generic solution. Be aware that depending on your application and the desired level of security, it may take quite some effort for initial setup and continuous monitoring, adjustments, fine-tuning and maintenance.
  • Perform security and penetration tests on your environment and application.
    There are 3rd party vendors that offer services to test your application and environments. Please note that in my practical experience, I've rarely (if at all) seen a security audit that found product related issues within AEM. Almost all findings could be tracked down to custom application development performed by the project.
    In addition to that, I am aware of two additional AEM-specific resources that may help you testing your installation on your own:
  • Refer to the valuable resource listed by @Bhuwan_B to get additional insights on XSS in the context of AEM

 

Probably not the answer that you were looking for but hopefully this still helps.

View solution in original post

4 Replies

Avatar

Level 4
Hi Bhuwan_B, I checked these link. Unfortunately, it doesn't give me an answer. I need to know how to prove these vulnerabilities are fixed in my AEM.

Avatar

Community Advisor

You can check for Tools available for Website Penetration Testing to validate your sites for Vulnerabilities.

Avatar

Correct answer by
Employee Advisor

Hi @ariesyinn!

As already pointed out in your other thread, AFAIK there is no public information available on the exact nature of the two mentioned specific vulnerabilities. So unfortunately I don't see any way to reproduce the attack vectors and to directly verify if your AEM environment is still vulnerable for these exact issues. While you could test your application for some kind of XSS, this would still not give you any insights for these two specific vulnerabilities. XSS is a very broad field. I tried to find some more details about the nature of the vulnerabilities by their CVEs (as you probably did as well) but was unable to find any public source for it.

 

I've already outlined how to verify the version (incl. SP and CFP) that is installed on your AEM instance. That's one first and strong indicator that your environment should no longer be vulnerable to these two specific attack vectors. However, in IT security there is no way to guarantee a 100% secure system.

 

The rewrite rules that you shared from your dispatcher configuration provide some level of protection against certain XSS attacks. However, the field of XSS is very wide and there may still be other attack vectors that could possibly get past these simple rewriting rules. (Please note: while mod_rewrite can help to provide a certain level of basic protection, it is not a dedicated security tool.)

 

If you have enhanced security requirements (as often seen for customers from e. g. the financial sector), I recommend to:

  • Follow Adobes AEM Security Checklist
  • Follow Adobes Dispatcher Security Checklist
  • Follow recommended best practices during the development cycle as pointed out in these Security Considerations
  • Keep your overall software stack as up-to-date as possible. This does not only mean AEM but also your operating system, your Java runtime (JRE), 3rd party libraries that you are using, etc.
    In this context I would also recommend to evaluate if you want to upgrade AEM to a more recent version (6.5 for on-premise). According to Adobes end of life matrix, AEM 6.2 has run out of core support two years ago and even extended support ended last month (April 2021). So there will be no additional updates from Adobe for your specific version of AEM. If you really care about security, running an unsupported AEM version is probably one of the bigger security concerns you should look at. The very least that I would recommend is to upgrade to the latest available CFP for AEM 6.2 (SP1-CFP20) which has been released almost two years ago.
  • Evaluate some kind of Web Application Firewall (WAF).
    A popular choice I've seen in projects is mod_security with the OWASP Core Rule Set (CRS). The rule set contains protection against a wide range of attack vectors, including XSS. It's not AEM-specific but a generic solution. Be aware that depending on your application and the desired level of security, it may take quite some effort for initial setup and continuous monitoring, adjustments, fine-tuning and maintenance.
  • Perform security and penetration tests on your environment and application.
    There are 3rd party vendors that offer services to test your application and environments. Please note that in my practical experience, I've rarely (if at all) seen a security audit that found product related issues within AEM. Almost all findings could be tracked down to custom application development performed by the project.
    In addition to that, I am aware of two additional AEM-specific resources that may help you testing your installation on your own:
  • Refer to the valuable resource listed by @Bhuwan_B to get additional insights on XSS in the context of AEM

 

Probably not the answer that you were looking for but hopefully this still helps.