Jump to content

Layered Navigation Security hole ? Possible denial of service attack crash down server.


dctremblay

Recommended Posts

Hi !

We're running a Prestashop 1.6 instance with approx 1200 products with average of 5 declinations each.

I noticed that since few weeks, our server is often crashed down, so I decided to investigate.

When I received monitoring server down alert, I immediately checked the logs to see the latest request (the one that may possibly crashed down the website).

Here's what I've seen :

70.80.151.18 - - [19/Nov/2017:22:15:31 -0500] "GET /modules/blocklayered/blocklayered-ajax.php?layered_id_attribute_group_6=6_1&layered_id_feature_20=20_1&layered_id_feature_14=14_3&laye
red_id_feature_18=18_4&layered_id_feature_129=129_6&layered_id_feature_143=143_8&layered_id_feature_149=149_10&layered_id_feature_160=160_12&layered_id_feature_164=164_13&layered_id_feat
ure_491=491_17&id_category_layered=53&layered_price_slider=19_165&orderby=date_add&orderway=desc&n=15&p=2&_=1511147621304 HTTP/1.1" 499 0 "https://www.XXXXXX.ca/fr/53-robes-soleil" "Mo
zilla/5.0 (Linux; Android 7.0; SM-T580 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.116 Safari/537.36" "-"

So the problem seems to comes from the Layered Navigation module.

When I type the "top" command, I see that MariaDB/MySQL process is running full throttle, so here's what "SHOW PROCESSLIST" says :

| 63 | XXXXXX | localhost       | XXXXXX_www     | Query   |    5 | statistics | SELECT fl.name feature_name, fp.id_feature, fv.id_feature_value, fvl.value, COUNT(DISTINCT p.id) |    0.000 |

Then I decided to reproduce manually the crash : I go on the frontend website, go on a category and then click lots of layered navigation filters. Guess what happened ? Server crashed down ! So I guess that too much filters makes a SQL query with very big complexity, bottlenecking the website.

Other than remove layered navigation, decrease max execution time of query, or set less filters choices, is there's a way to fix this ? Is this problem fixed with Prestashop 1.7 ?

Thank you very much and have a great day !

Edited by dctremblay (see edit history)
Link to comment
Share on other sites

You should be able to reproduce the issue by running the suspected query directly against mysql/maria outside of Prestashop.

First run the query using phpmyadmin, just to confirm how long they are taking.  If it is taking too long, then you might need to investigate changing the query or optimizing the tables based on how much data you have.

Then you can also create a small php script that executes the same statement, and then run that script from multiple browser windows and see if you can crash the server.  If you can't then you might need a load tool to run that script for you many times until it crashes.  This will help you confirm the issue outside of Prestashop, and also allow you to experiment with different optimized queries or table structures.

I can't imagine that Prestashop does much performance testing of their store and modules, so things have a tendency to work with a small catalog and small number of users, but once you go beyond a small catalog and increase the load on the store, then things start to go sour

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...