256 Kilobytes

3.5 Web Dev Security Considerations You Didn’t Know About

Articles in Hacking the Government | By August R. Garcia

Published 6 months agoSun, 21 Apr 2019 01:31:32 -0700 | Last update 6 months agoSun, 21 Apr 2019 05:22:14 -0700

Despite the obscene amounts of time that goes into computer security, there are always new computer security vulnerabilities, bugs, and exploits being discovered, created, and exploited by hackers.

6,210 views, 0 RAMs, and 0 comments

Despite the obscene amounts of time that goes into computer security, there are always new computer security vulnerabilities, bugs, and exploits being discovered, created, and exploited by hackers.

Whether you’re a programmer for a corporation, a freelance developer, affiliate marketer, SEO guru, or run a personal site, understanding the types of exploits that exist is good for, you know, obvious reasons.

Exploiting Compression Algorithms to Break HTTPS

How HTTPS Works

Assuming they are configured correctly, websites that serve their content over HTTPS will encrypt the data sent over the web prior to sending it to prevent sensitive data from being intercepted. However, compressing data before sending it over the Internet can introduce vulnerabilities that allow this encryption to be compromised.

How Compression Algorithms Work

When working with web development, transferring data over the Internet is one of the largest bottlenecks. Fortunately, it’s easy to use compression algorithms like GZip to compress a website’s files on the server side before sending them to the client. It’s generally much faster to have the user’s computer decompress the files on their end than it is to transfer substantially larger, non-compressed packets over the Internet.

While there are many different compression algorithms, they are similar in concept:

  1. Find patterns;
  2. Algorithmically describe the patterns in a way that they can be reconstructed;

Pseudocode examples of this might include:

  • Replacing “AAAAAAAAAAAAAAAAAAAA” with “Ax20”
  • Creating a legend at the top of a file for long words (1=watermelon; 2=factory; etc) and then replacing all instances of those words with their keys

The CRIME Vulnerability

In 2002 the Compression Ratio Info-Leak Made Easy (CRIME) exploit was published, taking advantage of compression algorithms to break HTTPS encryption. Consider a scenario where an attacker is able to:

  • Observe the filesize of the encrypted packet sent from the client to the server; and
  • Is able to make repeated, slightly altered requests to the server

Making slight additions to these requests allows and observing the impact that these changes have on the packet size can be used to infer whether particular strings appear elsewhere in the encrypted packet. Through repeated requests, an attacker can deduce the packet content, which can be used to, for example, steal a user’s login cookie.

While the original CRIME vulnerability has been largely patched, variations and other conceptually-similar attacks use the same basis, including:

Exploiting Different Parser Behaviors

How Do Browsers Parse Code?

HTML, JavaScript, and other computer code only has meaning after it is parsed by an interpreter to determine what the code actually means. While there are standards for how HTML, CSS, JavaScript, and other computer code should be parsed, there are differences in how certain cases may be handled between different interpreters. For example, consider the following line of JavaScript:

function something(str){
  alert(str)
}

While there is no semicolon after the alert statement, in this scenario, JavaScript parsers will generally infer an implicit semicolon due to the newline. However, the exact behavior can vary based on the implementation of the specific JavaScript parser being used. These types of minor differences can result in code behaving differently depending on how it is parsed.

Exploiting Parse-Type Order

Webpages generally contain multiple types of code. An HTML document, for example, may include JavaScript code inside of an element’s “onclick” attribute. Because of this, it can be possible to exploit browser parse order to, for example cause user-input to be decoded before being interpreted by the JS engine. This type of vulnerability received a fair amount of attention in March-April of 2019, being used as part of an XSS vulnerability on Google’s homepage, as discussed by Live Overflow and explained in more depth in a second video.

Affiliate programs, such as these high quality deals that you should buy, generally work by providing affiliate marketers with an affiliate tracking code that can be inserted into URLs--generally as a URL parameter such as site.com/arbitrary-page?affiliate-code=256kb--which then can then promote with the finest affiliate marketing techniques. When users click on these links:

  1. The user is taken to the target page; then
  2. Once the user is on that page, that site tells the user’s browser to store a tracking cookie to remember who referred them.
  3. The cookie generally lasts for anywhere from 24 hours up to a few months. If the user purchases from the site while the cookie is active, the marketer gets a commission. Note that many affiliate programs will only pay the commission to the most recent cookie awarded, in the case that multiple affiliate marketers refer the same person.

However, it is possible to set up a site that, instead of having users actually click a link, directly give the affiliate cookie to visitors’ browsers without actually sending the user to the company’s storefront. In addition to the obvious fact that this generates no value for the company that is paying out these commissions, this can also overwrite the affiliate cookies of other legitimate marketers.

Because cookie stuffing is not focused on generating targeted traffic, it is instead focused on shotgunning out as many affiliate cookies as possible in the hopes that someone happens to buy something on one of many sites. An Offbrand-Buzzfeed article that gets even a mild 5,000 views, each stuffed with affiliate cookies, can result in many fraudulent commissions through pure chance. Here’s some math, for the lulz:

  • The Amazon Affiliate tracking cookie lasts 24 hours
  • Assume these probably-low estimates that the average person:
  • With 5,000 fraudulently stuffed cookies:
    • (1/365)*5000 would mean that 5000 fraudulent cookies would result in roughly 13.7 sales by pure chance
    • $300 * 3% commission * 13.7 sales is $123.30

Scale with cookies for more programs and more clickbait trash until you get banned from all affiliate programs and/or arrested for fraud.

From the perspective of a web developer or site owner, it is important to take into account the possibility of user-generated content resulting in cookie stuffing.

  • If you run an affiliate program, be cautious of who you approve and how you implement your program, for obvious reasons. Also be aware of abnormal conversion rates, a lack of correlation between the time that a user’s cookie is given and conversion time (users should generally be more likely to convert shortly after clicking the link), and other suspicious trends.
  • If your site allows for user-input, consider the potential for cookie stuffing through comments, images, and other input. Cookie stuffing code injected into the comments of a popular article has the potential to result in thousands of dollars worth of fraud.

Of course, not only are these techniques grounds for companies to terminate their marketing relationship with you, it turns out that it’s actually more profitable to actually do a good job. Rather than getting sued by eBay, clear up your affiliate marketing misconceptions or become a subscriber and follow along with Hash Brown’s 10 Days to Amazon Sales course.

Bonus: User Privacy and the :visited Selector

Back in my day, links that you hadn’t visited were blue and :visited links were purple. While this was useful for determining which Reddit links you had already clicked on, until 2010 there were substantial privacy issues surrounding the application of styles to visited links. Consider the following concept:

  1. Set up a website
  2. Get a list of the 10000 most visited websites
  3. Include <a> tags to these pages somewhere on your website and hide them from the use with CSS
  4. Use JavaScript to detect which ones are purple
  5. Asynchronously send that data back
  6. Congratulations, you now know a huge amount of information about your users’ browser history, which you can then use to infer demographic information, interests, and other profitable information.

Except, you don’t actually have this information because if you’re living in 2019, since these privacy concerns are handled by:

  • Telling the window.getComputedStyle and similar methods to “always return values indicating that a user has never visited any of the links on a page”; and
  • Restricting the styles that can be applied to :visited links with a whitelist that only color-related CSS to be applied.

While there are theoretically some ghetto hacks that you could use to attempt to infer this data, as far as I can tell, this vulnerability is, in fact, patched. Since you cannot change the size, position, and/or visibility status of :visited links, most of the obvious ghetto hacks--such as attempting to infer what links are visited based on their position on the page--are prevented.

If anyone comes up with a work around and posts it in the comments, I’ll be proud of you.

In Conclusion

Understanding web security issues is useful for obvious reasons. Now that you know about these considerations, learn more about related topics like user-agent spoofing, proxies used for webspam, integer overflows, and client-side input validation. Or subscribe and check out the subscriber-exclusive eBook on web spam in 2019.

Download more RAM. 🐏 ⨉ 0 Posted by August R. Garcia 6 months ago

Edit History

• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
• [2019-04-21 1:31 PDT] August R. Garcia (6 months ago)
🕓 Posted at 21 April, 2019 01:31 AM PDT

Profile Photo - August R. Garcia August R. Garcia LARPing as a Sysadmi... Portland, OR
🗎 198 🗨 985 🐏 299
Site Owner

Grahew Mattham

August Garcia is some guy who used to sell Viagra on the Internet. He made this website to LARP as a sysadmin while posting about garbage like user-agent spoofing, spintax, the only good keyboard, virtual assitants from Pakistan, links with the rel="nofollow" attributeproxiessin, the developer console, literally every link building method, and other junk.

Available at arg@256kilobytes.com, via Twitter, or arg.256kilobytes.com. Open to business inquiries based on availability.


Account created 11 months ago.
198 posts, 985 comments, and 299 RAMs.

Last active 5 hours ago:
Commented in thread [Discord] Syntax highlighting?

Post a New Comment

To leave a comment, login to your account or create an account.

Do you like having a good time?

Read Quality Articles

Read some quality articles. If you can manage to not get banned for like five minutes, you can even post your own articles.

View Articles →

Argue with People on the Internet

Use your account to explain why people are wrong on the Internet forum.

View Forum →

Vandalize the Wiki

Or don't. I'm not your dad.

View Wiki →

Ask and/or Answer Questions

If someone asks a terrible question, post a LMGTFY link.

View Answers →

Make Some Money

Hire freelancers and/or advertise your goods and/or services. Hire people directly. We're not a middleman or your dad. Manage your own business transactions.

Register an Account
You can also login to an existing account or recover your password. All use of this site is subject to terms outlined in the terms of service and privacy policy.