Handling the 2 Most Common Store Error Types

  • MisterEd
  • Topic Author
  • Offline
  • Administrator
  • Administrator
More
4 years 6 months ago - 4 years 6 months ago #22 by MisterEd
here are two errors that happen more frequently than others:
  1. Missing STATIC HTML page errors: This error happens when a URL is contains &cartlink= or &page= (the 2 types of STATIC HTML pages we use) and cannot be found, or in other words it is broken, mistyped, or just plain or missing )not created). While this error logging is useful for finding out if a &cartlink= or &page= type links are broken or missing, there are attacks used frequently by script kiddies and others trying to see if they can create an SQL injection vulnerability to compromise or download the database. You can tell these types of attacks as they will add something like 'A=0 on the end of the URL or a million different things like it but it always starts with a quote and then tries to do what we call a variable set. This does not work on AgoraCart stores. Instead, to your store this looks like a page request and so it will try to find a page that does not exist. When that error happens, the error is logged. If emails are enabled, you will also get an email with the error details. The "visitor" then is routed to a error 405 (not allowed) with proper error headers.

  2. Missing cart session errors: The cart sessions are used to track your customer's session do expire within the time period you set in your main settings. When this happens and they try to visit checkout, view cart, or other things that rely on a cart session built into the URL or form submit, then they will get an error screen but the cart session will be rebuilt as if new and the error logged. If emails are enabled, you will also get an email with the error details. This type of errors are good for spotting cart IDs that are built into your URLs. Route 66 has been optimized to not require cart IDs in regular links as most people use cookies now. This error happens from time to time when someone might bookmark a URL that includes a Cart ID and then come back to find their cart session has expired (but it is rebuilt automatically once they navigate the storefront). Can also happen from sharing a URL or cutting and pasting a URL into other parts of a website. If the visitor is not the owner of the cart session, then the error is generated, logged, and emailed every time the link is visited. This can fill up your error logging with lots of these errors.


In the Route 66 version, I just added some additional features to help you manage the error logging of these types of errors.

Error Logging Controls: Now Route 66 version starting with 06.6.00.0008 (March 22, 2020 and later) brings the ability to enable/disable error logging for these 2 most common error types individually: missing cart sessions and missing STATIC HTML pages. It also allows you to turn off error emails that contain the error details. IF you disable one of the logging of the 2 common error types, then the emails for that error is also skipped. You can also disable all error email messages. Those not disabled will still show up in the error logs, such as for freeform code that fails, bad plugin code errors, typos in code, missing files or sub routines, etc. You can set these up in your Store Settings > Main/Core Settings > misc tab.


Additional Tips:

These types of attacks fill up the error logs very quickly so your error logs need to be examined and emptied regularly and that frequency depends upon your traffic volume.

If you notice some common elements to the errors, you can take the following actions per each type of common element:
  • IP addresses repeatedly used for attacks or missing files: If you notice IP address that are used frequently for the same type of error or multiple types of errors, then make note of those IP addresses. The IPv4 addresses are 4 sets of 1 to 3 digits divided linked together by period characters (IPv6 is more complicated). Then block them in your firewalls or if your hosting account has a feature to add IP addresses to a block list, add them there. If the last set of 1-3 numbers is different, but the rest first 3 sets are exactly the same in many of the IP addresses you wish to block, then you can combine them by changing one of the IP addresses to the zero (0) digit for the last number set and adding a forward slash (/) and the number 24 to the end and use that to cover all those IP addresses. For example, say you have these 3 IP addresses: 120.2.34.1, 120.2.34.89, 120.2.34.199, instead of entering each one individually you can combine them and enter one IP entry that looks like: 120.2.34.0/24 and it will cover all the current and future IP addresses that try to attack from an IP address starting with 120.2.34.
  • the same exact STATIC HTML page missing: If the page exists but has extra characters after the .html portion of the static html page URL attribute that don't make sense then it is likely an injection attack and you should check for the IP address and block an IP address that is attacking frequently. If a genuine page error that is missing, either create it with the STATIC HTML page managers (by page type) or look for the links on your site or in your marketing and remove them. If it looks like a legit page but is not something you ever setup or used previously nor is in your site links and designs, then it can be a likely test of some sort and you can ignore if nothing seems to connect it to an attacker.
  • the same exact cart session is missing: This can indicate that a link in your site or designs has a cart ID built into the link URL. Search and remove cart IDs from all your site pages and store designs. If you have a site map generator that automatically builds a site map and includes cart IDs, you will need to make sure that site mapper appears to be a bot (cofiguration wise) if you have access to its settings. If not you may need to either find a new site mapper or turn off cart session errors.
  • random cart sessions are missing, but frequently: This can indicate that your cart session expire settings in the Main/Core settings are shorter than needed. Adjust those as needed to a longer span of time. However, it is not recommended to go over 5-7 days for busy sites, nor 30 days for any site. If you are using a payment gateway that reports back a delayed payment (such as for Echeck clearing), then you will need to allow for 4-5 days for cart session expiration, depending upon the gateway.
Last edit: 4 years 6 months ago by MisterEd.

Please Log in or Create an account to join the conversation.

Time to create page: 0.280 seconds
Powered by Kunena Forum