My very own accidental DoS program
-
During the holiday downtime last week I finally took the time to install a Let's Encrypt cert on the company's self-hosted web server. Because I'm impatient and not willing to wait hours for a txt record to propagate, I used the simple challenge test for a single named server. (wildcards require the txt method for verification) The cert was created for the canonical server name meaning that requests with the www prepended failed. No problem, just add a couple of new url rewrite rules, one to remove the www. and the other to redirect to force https. It worked like a charm...or so I thought. A week goes by without any reported problems until a customer goes to renew their contract. (desktop app) That's when all hell broke loose. :wtf: The desktop app sends a request to a registration web app hosted on that server that takes the querystring params and sends back a response indicating if the account is in good standing. This has worked well for many, many years so I was surprised when it started misbehaving. The problem turned out to be the querystring params were doubling. :confused: This was happening as a result of the url rewrite even though I had included the option to not append the querystring. :doh: This was a problem due to the way multiple querystring paramaters with the same name are handled...basically, resource.aspx?sID=2&sID=2 resolves to '2,2'. Try parsing that to an int! (also, another reason to use TryParse vs. Parse) Now, while that webpage/app was throwing a 500, the client-side app that was calling it became aware that an error had occurred and re-requested the page. It was only supposed to retry a maximum of 10 times before quitting...however, a line of code that made the request was mistakenly left right before the quit condition.... :omg: ...so, no matter what the fail counter said, it was going to keep trying...at least until the short variable hit it's limit! This resulted in an unresponsive app for the client that had to be killed manually as well as a royal mess in the server's WC3 log. :doh: Since this webserver is also used by other customers, I had to resort to handling the double parameters in the registration web app until after hours when I could correct the url rewrite rule. (use {URL} instead of {REQUEST_URI} in the redirect) In all, I had around a dozen different apps to fix on the server plus fixing and redeploying the desktop app. :sigh: I was a bit surprised to realize that IIS's auto-ban had not kicked in until I discovered that it was not enabl
-
During the holiday downtime last week I finally took the time to install a Let's Encrypt cert on the company's self-hosted web server. Because I'm impatient and not willing to wait hours for a txt record to propagate, I used the simple challenge test for a single named server. (wildcards require the txt method for verification) The cert was created for the canonical server name meaning that requests with the www prepended failed. No problem, just add a couple of new url rewrite rules, one to remove the www. and the other to redirect to force https. It worked like a charm...or so I thought. A week goes by without any reported problems until a customer goes to renew their contract. (desktop app) That's when all hell broke loose. :wtf: The desktop app sends a request to a registration web app hosted on that server that takes the querystring params and sends back a response indicating if the account is in good standing. This has worked well for many, many years so I was surprised when it started misbehaving. The problem turned out to be the querystring params were doubling. :confused: This was happening as a result of the url rewrite even though I had included the option to not append the querystring. :doh: This was a problem due to the way multiple querystring paramaters with the same name are handled...basically, resource.aspx?sID=2&sID=2 resolves to '2,2'. Try parsing that to an int! (also, another reason to use TryParse vs. Parse) Now, while that webpage/app was throwing a 500, the client-side app that was calling it became aware that an error had occurred and re-requested the page. It was only supposed to retry a maximum of 10 times before quitting...however, a line of code that made the request was mistakenly left right before the quit condition.... :omg: ...so, no matter what the fail counter said, it was going to keep trying...at least until the short variable hit it's limit! This resulted in an unresponsive app for the client that had to be killed manually as well as a royal mess in the server's WC3 log. :doh: Since this webserver is also used by other customers, I had to resort to handling the double parameters in the registration web app until after hours when I could correct the url rewrite rule. (use {URL} instead of {REQUEST_URI} in the redirect) In all, I had around a dozen different apps to fix on the server plus fixing and redeploying the desktop app. :sigh: I was a bit surprised to realize that IIS's auto-ban had not kicked in until I discovered that it was not enabl
Fun or what. Services, with people using them, and expecting better. :doh:
-
During the holiday downtime last week I finally took the time to install a Let's Encrypt cert on the company's self-hosted web server. Because I'm impatient and not willing to wait hours for a txt record to propagate, I used the simple challenge test for a single named server. (wildcards require the txt method for verification) The cert was created for the canonical server name meaning that requests with the www prepended failed. No problem, just add a couple of new url rewrite rules, one to remove the www. and the other to redirect to force https. It worked like a charm...or so I thought. A week goes by without any reported problems until a customer goes to renew their contract. (desktop app) That's when all hell broke loose. :wtf: The desktop app sends a request to a registration web app hosted on that server that takes the querystring params and sends back a response indicating if the account is in good standing. This has worked well for many, many years so I was surprised when it started misbehaving. The problem turned out to be the querystring params were doubling. :confused: This was happening as a result of the url rewrite even though I had included the option to not append the querystring. :doh: This was a problem due to the way multiple querystring paramaters with the same name are handled...basically, resource.aspx?sID=2&sID=2 resolves to '2,2'. Try parsing that to an int! (also, another reason to use TryParse vs. Parse) Now, while that webpage/app was throwing a 500, the client-side app that was calling it became aware that an error had occurred and re-requested the page. It was only supposed to retry a maximum of 10 times before quitting...however, a line of code that made the request was mistakenly left right before the quit condition.... :omg: ...so, no matter what the fail counter said, it was going to keep trying...at least until the short variable hit it's limit! This resulted in an unresponsive app for the client that had to be killed manually as well as a royal mess in the server's WC3 log. :doh: Since this webserver is also used by other customers, I had to resort to handling the double parameters in the registration web app until after hours when I could correct the url rewrite rule. (use {URL} instead of {REQUEST_URI} in the redirect) In all, I had around a dozen different apps to fix on the server plus fixing and redeploying the desktop app. :sigh: I was a bit surprised to realize that IIS's auto-ban had not kicked in until I discovered that it was not enabl
I'll admit I did not read all that. But a year ago I ran into a problem at a company I was working for. There was another company that provide I black box, literally. Basically, it ask for some information and our system was too slow to provide it. So, it ask again. The issue was that we provided the information after a couple of request's, but it kept asking over and over again. I wrote a simple application to figure out what was going on. It turned out that the query (question) was ask continuously over a long period of time and all the answer's where apparently ignored. Do to a bad design (in my opinion), we had over a 128 threads (up/down over time) querying the database for the same information that we had already provided to the black-box. It is my one and only experience of having a piece of equipment perpetrating a DOS attack on a system; even if it was not intentional.
INTP "Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra "I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone