884485 - Consider sanitization of MakeAPI title and description fields

Status: RESOLVED WONTFIX

(Webmaker Graveyard :: MakeAPI, defect)

Description

[David Humphrey (:humph)]

We should consider adding some checks/sanitization around what goes into the MakeAPI, such that web content can trust it (more) when displaying in UI.  We have code for this in Popcorn Make now.  We don't want to double-escape things if tools are also doing it; but should figure this out.

Comment 1

[Pomax]

by when do we want this done?

Comment 2

[David Humphrey (:humph)]

I think before we open the API to external users we should add this.  Cade?

Comment 3

[Chris DeCairos (:cade)]

Two options here are:

a) Escape <>'"& in those fields as they come in.

Or

b) Clearly document that consumers should escape data before using it, and create a TOS that absolves us of responsibility for damages possibly caused by not escaping data

I like [a] because it makes me sleep better knowing we're not storing malicious strings. One potential problem is double escaping, if the app that creates the make escapes data before posting it to the create or update routes. It'd require clear documentation for Consumer apps of the MakeAPI that escaping will be handled internally on make creation/updating.

With external consumers of the MakeAPI being a long term goal, option [b] sounds like it will discourage applications from wanting to use the service.

Comment 4

[David Humphrey (:humph)]

I'd do a) as well.  Downstream clients can learn to deal with the fact that we escape, it's not our problem--we just need to document it.  Let's make sure we get good test coverage for this when it lands.

Comment 5

[Jon Buckley [:jbuck]]

The problem with escaping is that you don't know what context the data will be used in, so you don't know what's safe to escape and what isn't. The solution you propose is essentially an escaping RPG. The last point in the chain, typically the server sending data to the client, is best equipped to know what escaping needs to be done.

Comment 6

[Jon Buckley [:jbuck]]

We've covered security issues in other bugs