Content Security Policies #202

AlexMaxHorkun · 2019-07-08T20:12:57Z

Problem

CSP not implemented in Magento

Solution

Implement CSP in Magento in a backward compatible way and allow extension developers to configure it

Requested Reviewers

DrewML · 2019-07-08T21:47:16Z

To support a (useful) CSP in the current state of Magento, we'd have to allow unsafe-inline and unsafe-eval, because:

Magento relies on (and has encouraged) inline script tags, so they're all over both core and 3rd party extensions
Magento's templating variable replacement and bundling features both use eval (awful, awful, awful, but that's the state of things).

Those 2 escape hatches effectively nullify (most of) the value of a CSP. (Opinion) Any plan for a CSP in core should include a plan for tackling those problems.

DrewML · 2019-07-08T21:49:44Z

Magento will provide a default endpoint to receive these reports.
Since there is no way to authenticate a genuine report and on a live store they can fill up quickly the number of
reports stored in the database will be limited to 10000 deleting old ones when the limit is reached.

I'm not sure if this strategy will provide value as a default. As an attacker, it shouldn't be hard to spam the endpoint with dummy data 10k times to hide more nefarious activity in the logs. Developers can obviously customize this default, but good defaults are important for a security feature.

Imagine an attacker running this code locally (pseudo-code):

for i = 1 to 10000:
   http.post('${magento-store-url}/csp-endpoint', fakePayload)
   ## logs of any prior bad activity are now purged
end for

AlexMaxHorkun · 2019-07-08T22:06:52Z

To support a (useful) CSP in the current state of Magento, we'd have to allow unsafe-inline and unsafe-eval, because:

Magento relies on (and has encouraged) inline script tags

Magento's templating variable replacement and bundling features both use eval (awful, awful, awful, but that's the state of things).

Those 2 escape hatches in CSP effectively nullify the value of a CSP. Any plan for a CSP in core should include a plan for tackling those problems.

I agree that our need to allow unsafe-inline and unsafe-eval reduces CSP usefulness but it would still help mitigate certain types of XSS attacks laying the groundwork for further adoption of more strict policies

AlexMaxHorkun · 2019-07-08T22:42:57Z

Magento will provide a default endpoint to receive these reports.
Since there is no way to authenticate a genuine report and on a live store they can fill up quickly the number of
reports stored in the database will be limited to 10000 deleting old ones when the limit is reached.

I'm not sure if this is a good default. As an attacker, it shouldn't be hard to spam the site with automated browser instances and trigger 10k events to hide more nefarious activity in the logs. Developers can obviously customize this default, but good defaults are important for a security feature.

The proposed limit is only there to limit the storage usage and prevent DoS attacks. It is assumed that developers that care about CSP will use restricted mode instead of report-only mode so there would be no incentive for an attacker to flood the reports to hide their attacks since their attacks would be blocked by CSP anyway.

YevSent · 2019-07-09T21:34:45Z

The proposed limit is only there to limit the storage usage and prevent DoS attacks. It is assumed that developers that care about CSP will use restricted mode instead of report-only mode so there would be no incentive for an attacker to flood the reports to hide their attacks since their attacks would be blocked by CSP anyway.

Enabling SCP in restricted mode depends on not only merchants and their SI but on 3rd party extensions installed on merchant's websites as they should be updated to support SCP before enabling restricted mode.

YevSent · 2019-07-09T20:57:52Z

design-documents/csp.md

+we set event listener via attributes and we use eval in template.js so we'd have to also allow
+'unsafe-inline' and 'unsafe-eval'. Magento has integrations with multiple 3rd party services like vimeo, youtube,
+google analytics and various payment systems which we must whitelist additionally.
+That will be the default whitelist Magento provides out of the box packaged alongside related modules via _csp\_whitelist.xml_.


Each module should provide own scp_whitelist.xml for 3rd party resources.

that is what I meant

YevSent · 2019-07-10T14:51:42Z

design-documents/csp.md

+
+CSP API/SPI will consist of the following interfaces:
+
+* Policy DTO. The interface has only policy ID because not all CSP policies look like _\<policy name\> \<value\> \<value\>_,


Could you provide some details about different policy formats? I did not find any information about it in RFC. Or are you talking about serialized SCP?

examples would include plugin-types, report-to, sandbox and some other policies that either require additional headers to work or at least accept different values than URIs and preserved 'self'/'unsafe-inline' words like *-src policies do

Probably I'm not clear understand but plugin-types, report-to, sandbox have the same format <policy name/> <value/> <value/>;

I got confused, thought the question was related to the limitation of available policies through csp_whitelist.xml - for that file allowed options for values are important as well. report-to requires additional header and Subresource Integrity may involve Access-Control-Allow-Origin header to be implemented

melnikovi · 2019-07-10T15:37:26Z

design-documents/csp.md

+}
+```
+
+* A repository of violations logs collected when CSP reporting is enabled


Need to think how to make reporting works. I don't think we can't use Web API to capture the data, it would be just too much load. May need to build a separate service for capturing reports data.

we can use a regular controller as the report endpoint for browsers if our web API mechanism would be difficult to fit for this

YevSent · 2019-07-10T15:44:10Z

AngularJs provides a possibility to define SCP on a view level (directly in HTML), maybe this approach would allow us to avoid global usage of unsafe-inline and unsafe-eval?

AlexMaxHorkun · 2019-07-10T19:26:21Z

The proposed limit is only there to limit the storage usage and prevent DoS attacks. It is assumed that developers that care about CSP will use restricted mode instead of report-only mode so there would be no incentive for an attacker to flood the reports to hide their attacks since their attacks would be blocked by CSP anyway.

Enabling SCP in restricted mode depends on not only merchants and their SI but on 3rd party extensions installed on merchant's websites as they should be updated to support SCP before enabling restricted mode.

I understand that but if a merchant wants to enable CSP they can compensate for unsafe extensions by whitelisting resources those extension use themselves or make other changes to active policies

AlexMaxHorkun · 2019-07-10T19:34:50Z

AngularJs provides a possibility to define SCP on a view level (directly in HTML), maybe this approach would allow us to avoid global usage of unsafe-inline and unsafe-eval?

there is no way to use only certain policies for a portion of a page. If in the future we disable 'unsafe-inline' and a 3rd party-developer would need to reenable it for a specific page they would be able to do so with CSPAwareActionInterface

ericerway · 2019-07-10T20:29:45Z

@zetlen can we make sure this is incorporated into our approach for PWA? Better to do this sooner than later for the product since this affects content. Thanks!

DrewML · 2019-07-10T20:50:12Z

re: whitelisting, Google has a research paper where they analyzed and documented the effectiveness of deployed CSPs on the web.

I'm not finished reading through it yet (but will be :D), but this quote in the intro stood out:

Based on the results of our study, we conclude that maintaining a secure whitelist for a complex application is infeasible in practice

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf

Note that the alternative proposed in the paper's intro (strict-dynamic + nonces) is part of CSP Level 3, so I'd recommend looking into the feasibility of an implementation using that instead of whitelists.

AlexMaxHorkun · 2019-07-10T21:07:13Z

re: whitelisting, Google has a research paper where they analyzed and documented the effectiveness of deployed CSPs on the web.

I'm not finished reading through it yet (but will be :D), but this quote in the intro stood out:

Based on the results of our study, we conclude that maintaining a secure whitelist for a complex application is infeasible in practice

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/45542.pdf

Note that the alternative proposed in the paper's intro (strict-dynamic) is part of CSP Level 3, so I'd recommend looking into the feasibility of that.

that is an interesting point. This document is more focused on introducing CSP to Magento and allowing merchants/developers to configure policies, actual policies supplied by default with core Magento are up for debate

nathanjosiah · 2019-07-19T17:53:54Z

To support a (useful) CSP in the current state of Magento, we'd have to allow unsafe-inline and unsafe-eval, because:

Magento relies on (and has encouraged) inline script tags, so they're all over both core and 3rd party extensions

Magento's templating variable replacement and bundling features both use eval (awful, awful, awful, but that's the state of things).

Those 2 escape hatches effectively nullify (most of) the value of a CSP. (Opinion) Any plan for a CSP in core should include a plan for tackling those problems.

I don't think this comment has received enough attention. As it stands now, if the user has to enable these options and effectively open a huge hole in the security (and therefore the purpose) of this feature, is it worth implementing now without a solid plan to go with it?

… csp

AlexMaxHorkun · 2019-07-19T20:10:25Z

Added a bit about strategy going forward and whitelisting with nonce

AlexMaxHorkun · 2019-07-19T20:11:24Z

@DrewML @joni-jones do you have any objections?

nathanjosiah · 2019-07-22T15:22:57Z

Even with the added changes to the plan moving forward, I still have concerns about the false sense of security that this feature would provide in its current state. I understand that something is better than nothing in many cases but I think this would leave users way more vulnerable than they would feel they are. A large number of the security bugs that have been resolved in the current security remediation effort were related to eval. If we are knowingly using vulnerable libraries and the desire is to avoid the vulnerable feature, we should have an active plan to mitigate the risk.

We deprecated the entire Magento Backups feature because of similar concerns. We shouldn't be in such a rush to push a feature forward that we compromise on security especially when that is the entire point of the changes.

As a side note, I think it would be good to have the security team review security-related PR's as well as they may have some existing research to share.

DrewML · 2019-07-22T16:22:40Z

design-documents/csp.md

+
+It is possible to combine nonce and domain-list based whitelisting for CSP.
+
+Magento will have to generate unique nonce (using _Magento\Framework\Math\Random_) for each response and developers will


Is Magento/Framework/Math/Random cryptographically secure?

Yes, at the core it uses random_int which is.

DrewML · 2019-07-22T19:08:47Z

design-documents/csp.md

+To make it easier for developers and don't force them to include the nonce-helper to all of their blocks it will
+be available inside _.phtml_ templates via local `$nonce` variable.
+
+Additional effort will have to go to ensure proper nonce used/regenrated when page cache is enabled. Perhaps blocks


I think we need to spend more time on this section before merging this.

Additional effort will have to go to ensure proper nonce used/regenrated when page cache is enabled

Magento only has good performance in production with Varnish, and the nonce must be delivered in the response. If we were to release this without a full solution for caching, most merchants will take the speed and security they have today, rather than more security and massive performance regressions.

We need a plan for how we're going to deliver a unique nonce per request without disabling Varnish.

DrewML · 2019-07-22T19:14:42Z

design-documents/csp.md

+
+## Future steps
+To allow merchants to use whitelisting with _nonce_ we have to get reed of event handlers via HTML attributes and
+style attributes in our templates. There is no way to disable `unsafe-eval` since we use it for UI components and


There is no way to disable unsafe-eval since we use it for UI components and
some of the front-end libraries we employ need it (like jQuery).

There 100% is a way to do this, it's just a breaking change. If the work is scheduled, it can be done

As I stated in my comment above referring to this exact line

If we are knowingly using vulnerable libraries and the desire is to avoid the vulnerable feature, we should have an active plan to mitigate the risk.

getting reed of eval() in Magento front-end is a separate topic, obviously it has to be done but describing how would take another document.

DrewML · 2019-07-22T19:16:16Z

design-documents/csp.md

+style attributes in our templates. There is no way to disable `unsafe-eval` since we use it for UI components and
+some of the front-end libraries we employ need it (like jQuery).
+
+The work on refactoring templates to remove event handlers and _style_ attributes will be done after CSP is introduced


The work on refactoring templates to remove event handlers and style attributes will be done after CSP is introduced
gradually

This feels like the wrong order to me. How can we expect merchants to find the time to update their stores for CSP if we, Magento, can't find the time to do it first?

A good example of this is the @escapeNotVerified security work done several years ago.

https://magento.stackexchange.com/questions/92963/magento-2-escapenotverified

We still haven't completed this work in core, and it's been > 4 years.

We still haven't completed this work in core

Not to take away from your point, we just did it in the last few months. It will be delivered in the next patch releases.

To actually add to your point, it took the work of ALL core teams over 2 months of solid work to properly implement and test those changes. Totally unrealistic effort level for a typical merchant.

even with inline styles/JS present in templates we can utilize origin whitelisting for remote resources

DrewML · 2019-07-22T19:21:19Z

Because any work involving security is super important and super high impact, I'm going to list 2 requirements that I think are critical before this plan gets approved:

Review/approval from a member of the security team
A list of a few attack vectors that show that the proposed plan for CSP in Magento core would have prevented any of them (most I've gone through so far would not have been solved by this proposal)

piotrekkaminski · 2019-07-22T20:47:51Z

Couple other things:

i'm still waiting for info from Fastly if they could support nonces. Seems Varnish has a module to do that, but adding a regex parsing into Varnish might bring performance issues. https://docs.varnish-software.com/varnish-cache-plus/vmods/xbody/#javascript-csp-nonce
@szurek and @chandramadobes please review and comment
I'm pretty strongly against creating reporting functionality in Magento. We should integrate with report-uri.com which has a nice free plan and reasonable commercial plans. This will reduce project complexity and report handling is not a core commerce feature. We could consider some cooperation with them for cloud (and include XSS Auditor as well)
agree with @DrewML - it has to prove being able to stop typical attack (card skimmer loaded from weird site or inline JS directly in MiscHTML field

zetlen · 2019-07-22T22:32:19Z

For PWA Studio, I've created magento/pwa-studio#1453 to track our own progress. We don't have legacy code to migrate, so our job here will be much easier. @ericerway The rest of my comment will be about the more general case.

I agree with other commenters that a CSP with unsafe-eval in it is worse than nothing, because it leads to a false sense of security. I also agree that relying on empirical reporting to collect a list of exploit paths is an unreliable mechanism. It's better to enable the CSP only once the site is fully migrated.

However, we shouldn't wait to start building the "plumbing" for a CSP as this PR describes. That work has to happen anyway, and we don't need to advertise improved security while we're building the prototype.

We should support admin-configurable whitelisting. Whitelisting is less secure than nonce or hash, but as long as unsafe-eval and unsafe-inline are turned off, whitelisting is a measurable improvement which we can demonstrate. But it must be controllable by the system administrator, not assembled by merging extension configuration. It needs to be visible--if an admin doesn't recognize an approved domain, that's already a problem.

Once the plumbing is built, we should create a microsite that demonstrates some core Magento 2 functionality, like a single-product checkout. We should cut scope and functionality until it works with a properly secure CSP (no unsafe-eval or unsafe-inline. Then we should demonstrate its resistance to attack vectors.

Then we should iteratively add functionality to the microsite, fixing the script blocks where necessary.

Question for @DrewML, @piotrekkaminski, @AlexMaxHorkun , @nathanjosiah and others: Nonce-based whitelisting is expensive and potentially a cache buster. But what about hash-based whitelisting? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script Hashes can be generated at static deploy time, and they are guaranteed not to allow unexpected code to pass through.

kmddevdani · 2019-07-22T23:03:56Z

design-documents/csp.md

+
+CSP mode will be set with a config path not appearing in the admin configuration page so merchants
+would have to execute a CLI command in order to change it.
+


This sounds great:
It would protect the settings against changes via Admin (admins, hacked accounts, admin laptops with malware, ...). Only Dev/DevOps level could change it.
Is there a way to protect the configuration against badly written extensions, too?

Any possible problems with that on Magento Cloud? Related to read-only file system.

It would need to be written to the env.php file during the build process before deployment completes.

the hash comment is very good. can it be pre-generated once during deployment or the inline scripts are dynamic - if the latter it might cause caching issues too? definitely seems like an easier approach than nonces.

@piotrekkaminski I've added a bit about hashes

… csp

nathanjosiah · 2019-07-30T15:25:10Z

design-documents/csp.md

 _Magento\Framework\View\Page\Config\Renderer_ will add nonce to all css/js assets being added to a page. With _nonce_
 disabled the presentation class used inside templates will not add nonce when called and _Renderer_ will not do it as well.

-To make it easier for developers and don't force them to include the nonce-helper to all of their blocks it will
-be available inside _.phtml_ templates via local `$nonce` variable.
+Additional effort will have to go to ensure proper nonce used/regenrated when page cache is enabled. It is possible to


Maybe it would be good to have a more concrete understanding that this can actually be done. As stated by @DrewML Varnish support is integral to the success of this feature.

@nathanjosiah this helper will be used for hashes/dynamic origin whitelisting depending on the CSP mode selected by merchant so we'd have to have it. There is no conflict between hashes/whitelisted origins and using varnish

Usually, Varnish stores the gzipped content in the cache. It means that Varnish will be forced to decompress every cache entry, modify it and compress again for each HTTP request. This will definitely consume more system resources.

Also, we need to support third-party caching providers like Fastly.

Thus, please expand this section with a strategy for third-party providers and another impact on env, setup, etc.

using nonce alongside page cache doesn't seem viable right now, updated the section

kokoc · 2019-08-12T20:58:43Z

design-documents/csp.md

+There is no way to whitelist an event handler defined via an attribute though (like _onclick_) or styles defined
+with _style_ attribute that's why nonce will be
+disabled by default and all `unsafe-inline` scripts/styles will be allowed. Merchants who'll be successful in getting
+reed of all event handlers/styles defined using HTML attributes will be able to enable _nonce_ via configuration


spelling, reed = rid, multiple occurrences in the document.

kokoc · 2019-08-12T21:08:51Z

design-documents/csp.md

 _Magento\Framework\View\Page\Config\Renderer_ will add nonce to all css/js assets being added to a page. With _nonce_
 disabled the presentation class used inside templates will not add nonce when called and _Renderer_ will not do it as well.

-To make it easier for developers and don't force them to include the nonce-helper to all of their blocks it will
-be available inside _.phtml_ templates via local `$nonce` variable.
+Additional effort will have to go to ensure proper nonce used/regenrated when page cache is enabled. It is possible to


Usually, Varnish stores the gzipped content in the cache. It means that Varnish will be forced to decompress every cache entry, modify it and compress again for each HTTP request. This will definitely consume more system resources.

Also, we need to support third-party caching providers like Fastly.

Thus, please expand this section with a strategy for third-party providers and another impact on env, setup, etc.

piotrekkaminski · 2019-08-13T14:37:22Z

Fastly responded with a proof of concept of handling nonces through an ESI, however it would be best to use checksums or something similar instead of ESI. I assume the nonce/checksum doesn't have to change until there is a cache update (due to new code/changes being inserted on a page).

# INIT
# Generate nonce to be used in CSP and script tag
declare local var.nonce STRING;
set var.nonce = digest.base64(req.xid);
set req.http.x-nonce = var.nonce;

# Generate synthetic for filling in nonce
if (req.url ~ "900") {
  error 990;
}

# Disable compression for ESI handling
unset req.http.Accept-Encoding;

#FETCH
# Turn on esi
if (req.url ~ "/status/200") {
  esi;
}

#DELIVER
# Set CSP with nonce value generated in recv
if (req.esi) {
  set resp.http.Content-Security-Policy = "script-src 'nonce-"req.http.x-nonce"'";
}

#ERROR
# fill in esi tag with nonce value generated in recv
if (obj.status == 990 ) {
  set obj.http.Content-Type = "text/html";
  set obj.status = 200;
  set obj.response = "OK";
  synthetic {""}req.http.x-nonce{""};
}

… csp

AlexMaxHorkun · 2019-08-13T20:15:16Z

Fastly responded with a proof of concept of handling nonces through an ESI, however it would be best to use checksums or something similar instead of ESI. I assume the nonce/checksum doesn't have to change until there is a cache update (due to new code/changes being inserted on a page).

# INIT
# Generate nonce to be used in CSP and script tag
declare local var.nonce STRING;
set var.nonce = digest.base64(req.xid);
set req.http.x-nonce = var.nonce;

# Generate synthetic for filling in nonce
if (req.url ~ "900") {
  error 990;
}

# Disable compression for ESI handling
unset req.http.Accept-Encoding;

#FETCH
# Turn on esi
if (req.url ~ "/status/200") {
  esi;
}

#DELIVER
# Set CSP with nonce value generated in recv
if (req.esi) {
  set resp.http.Content-Security-Policy = "script-src 'nonce-"req.http.x-nonce"'";
}

#ERROR
# fill in esi tag with nonce value generated in recv
if (obj.status == 990 ) {
  set obj.http.Content-Type = "text/html";
  set obj.status = 200;
  set obj.response = "OK";
  synthetic {""}req.http.x-nonce{""};
}

If I understand correctly what they propose is for Varnish to dynamically replace a certain placeholder for every response but that is not secure since nothing will stop attackers from using the placeholder in their XSS attacks and have Varnish conveniently whitelist their scripts. This problem may be solvable but I think we should proceed without nonce-whitelisting. If we do to decide to include it later it will be just a matter of changing the configuration for merchants.

chandramadobes · 2019-08-22T21:06:09Z

Approved with future roadmap to address:

unsafe-eval and inline scripts
change from report only to strict mode.
Phased approach towards implementing CSP completely starting with report only mode.

content security policies

4213a8e

AlexMaxHorkun mentioned this pull request Jul 8, 2019

July, 10, 2019 #199

Closed

YevSent reviewed Jul 10, 2019

View reviewed changes

melnikovi reviewed Jul 10, 2019

View reviewed changes

updates

c82e553

paliarush self-assigned this Jul 16, 2019

paliarush approved these changes Jul 19, 2019

View reviewed changes

Oleksandr Gorkun added 3 commits July 19, 2019 14:31

nonce support

36e2b97

Merge branch 'master' of https://github.com/magento/architecture into…

8ae5038

… csp

nonce

620b153

DrewML reviewed Jul 22, 2019

View reviewed changes

zetlen mentioned this pull request Jul 22, 2019

[feature]: Add Content Security Policy to Venia magento/pwa-studio#1453

Closed

6 tasks

kmddevdani reviewed Jul 22, 2019

View reviewed changes

Oleksandr Gorkun added 2 commits July 23, 2019 12:50

updates

fcccf78

Merge branch 'master' of https://github.com/magento/architecture into…

345c55d

… csp

nathanjosiah reviewed Jul 30, 2019

View reviewed changes

paliarush assigned kokoc and unassigned paliarush Aug 5, 2019

kokoc suggested changes Aug 12, 2019

View reviewed changes

Oleksandr Gorkun added 2 commits August 13, 2019 14:47

Merge branch 'master' of https://github.com/magento/architecture into…

019e887

… csp

updates

d96e576

kokoc approved these changes Aug 23, 2019

View reviewed changes

kokoc merged commit 9c0378b into magento:master Aug 23, 2019


		CSP API/SPI will consist of the following interfaces:

		* Policy DTO. The interface has only policy ID because not all CSP policies look like _\<policy name\> \<value\> \<value\>_,


		It is possible to combine nonce and domain-list based whitelisting for CSP.

		Magento will have to generate unique nonce (using _Magento\Framework\Math\Random_) for each response and developers will


		CSP mode will be set with a config path not appearing in the admin configuration page so merchants
		would have to execute a CLI command in order to change it.

Content Security Policies #202

Content Security Policies #202

Uh oh!

Conversation

AlexMaxHorkun commented Jul 8, 2019

Problem

Solution

Requested Reviewers

Uh oh!

DrewML commented Jul 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

DrewML commented Jul 8, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexMaxHorkun commented Jul 8, 2019

Uh oh!

AlexMaxHorkun commented Jul 8, 2019

Uh oh!

YevSent commented Jul 9, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YevSent Jul 10, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AlexMaxHorkun Jul 10, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

YevSent commented Jul 10, 2019

Uh oh!

AlexMaxHorkun commented Jul 10, 2019

Uh oh!

AlexMaxHorkun commented Jul 10, 2019

Uh oh!

ericerway commented Jul 10, 2019

Uh oh!

DrewML commented Jul 10, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AlexMaxHorkun commented Jul 10, 2019

Uh oh!

nathanjosiah commented Jul 19, 2019

Uh oh!

AlexMaxHorkun commented Jul 19, 2019

Uh oh!

AlexMaxHorkun commented Jul 19, 2019

Uh oh!

nathanjosiah commented Jul 22, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DrewML Jul 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DrewML Jul 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nathanjosiah Jul 22, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DrewML commented Jul 8, 2019 •

edited

Loading

DrewML commented Jul 8, 2019 •

edited

Loading

YevSent Jul 10, 2019 •

edited

Loading

AlexMaxHorkun Jul 10, 2019 •

edited

Loading

DrewML commented Jul 10, 2019 •

edited

Loading

DrewML Jul 22, 2019 •

edited

Loading

DrewML Jul 22, 2019 •

edited

Loading

nathanjosiah Jul 22, 2019 •

edited

Loading

DrewML Jul 22, 2019 •

edited

Loading