SXA Search Endpoint Validation

In this article we learn about some opportunities to shield the SXA search endpoints from traffic that can produce noisy log messages.

Background

Our team frequently reviews the reports generated by a web application scanning software, an activity I highly recommend you incorporate into your process. In addition, we leverage aggregated log messages in another system (i.e. Elastic, Splunk) to better reveal what IIS and Sitecore experiences during the scans.

Research

One issue that seemed particularly interesting is related to the SXA search requests at the relative path //sxa/search/results and //sxa/search/facets. When the query string is invalid such as ?abc123 and ?l=abc123 the Sitecore logs will reveal exception messages due to the fact the query strings can't be properly bound or converted. It's not particular interesting until you see hundreds or thousands of the messages in a short window. I opened a support ticket with Sitecore and they acknowledged this as a bug (at least an issue up to SXA 10.3). Use reference number 589620 to track the progress of this issue.

Resolution

One solution provided by Sitecore support (during the interim period) is to apply a logging filter to exclude the messages.

An alternative solution is to globally prevent all of the abusive traffic from reaching your servers. If you are leveraging a CDN/Proxy product such as Cloudflare/Akamai you can deploy web application firewall rules to block the undesired traffic.

The following screenshot provides an example of rules you could put in place to reduce the noise. 

The rules perform the following:

• For each check we ensure that only the /sxa/search/ endpoints are evaluated.
• Reject query string parameters that contain an "L" parameter with anything other than a possible language (e.g. en-US).
• Reject query string parameters that do not reasonably match the values SXA is expecting.
• Reject POST method.
• Reject query string parameters with commands like "ping".

After making these changes we were able to reduce unnecessary traffic.

I hope you found this useful. One day you too might be investigating such a rare and peculiar issue. Good luck!

Troubleshoot Certificate Revocation Lookups

In this article we investigate an issue related to LetsEncrypt certificates configured for your web applications and services.

Background

Every so often we would notice in our non-production environment the custom contact forms would fail after the user submitted. These forms are built on top of Sitecore MVC and seemed to fail when the backend code attempted to POST to a service hosted by another team/party.

The error message we would see logged in the Sitecore log files looked like the following:

There are a few resources available online that describe possible causes for the error message and ultimately provide some kind of workaround to the problem.

The remote certificate is invalid according to the validation procedure.

• https://stackoverflow.com/questions/2675133/c-sharp-ignore-certificate-errors
• https://stackoverflow.com/a/66882479/1277533

Research

When reviewing our network we could not find anything that immediately stood out as the cause of the issue. If you make the assumption that calls to the web service are not yet happening, then the next logical thing to investigate are the steps .Net performs prior to making the outbound requests. 

I first confirmed that the web service URL can be reached. In my case the service has a URL to the Swagger UI available and that worked as expected. Second I checked that the LetsEncrypt root certificate was installed in the Trusted Root of the server; which it was. Finally, I used the certutil to verify the certificate which revealed some interesting results.

Running the utility output some key information we needed to determine next steps. As you can see in each of the following screenshots, the lencr.org domain is being accessed. Turns out that LetsEncrypt has a series of domains used to verify if a certificate is revoked. Read here for more details.

Resolution

Ultimately we had the Network/Security Teams put in place firewall rules to allow traffic to the various domains outlined here.

• *.o.lencr.org
• *.i.lencr.org
• *.c.lencr.org

I hope you found this useful. One day you too might be investigating such a rare and peculiar issue. Good luck!