Restrict leakage of private information via sites known or thought likely to be compromised

[pseudomonas]

Title:
Restrict leakage of private information via sites known or thought likely to be compromised

Area:
security

Summary:
As the DW code spreads and with more cross-site reading, it may become desirable to prevent sites with unpatched known security issues from reading locked entries.

Description:
If I have granted access to my locked entries to subscribers on a number of different DW-codebase sites, the compromising of one of those sites leads to the compromising of all my locked content.

Obviously I rely on trust when I grant access, and there are numerous ways that a remote server may be compromised. On the other hand, if a version/patch-level of DW is known to have a security problem (of a variety that allows an attacker to log in as another user), it might be preferable to prevent a site running that code from accessing my locked content. (perhaps only after a patch has been available for a given interval)

This could be done by remote sites advertising their version in headers when requesting content.

Advantages
* This might apply significant social pressure to remote sites to keep their code patched.
* This might flag up stagnant sites that are being improperly maintained.
* Sites with obsolete DW code might well be poorly-maintained with respect to other components as well (and indeed they could also advertise other software versions in the same way)
* Might prevent users dealing with this by fiddling with their personal access controls on too frequent a basis.

Disadvantages:
* Might complicate social arrangements at a time when it's more important to grow the community of sites using DW code than to ensure strict access controls.
* Might give false sense of security.
* A sufficiently bad security hole (eg arbitrary code execution) could allow an attacker to cause the site to lie about their versions.

I'm not sure what the analogous behaviour is with an OpenID provider that is known to be vulnerable to impersonation.

Poll #1105 Restrict leakage of private information via sites known or thought likely to be compromised

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
4 (12.5%)

Should be implemented with changes. (please comment)
3 (9.4%)

Shouldn't be implemented.
8 (25.0%)

(I have no opinion)
15 (46.9%)

(Other: please comment)
2 (6.2%)

Comments

[andrewducker]

I don't see why this should be D-W specific. It's all done via OpenID, right? So why not just have a black list of sites that are known to be unsecure?

[pseudomonas]

This might be a good way to do it so long as the model is a small number of big sites rather than everyone and their dog running a site and a few % of them being broken - it's still doable then but becomes a lot more reactive, and possibly a job for a full-time third party (as for mail server blacklists).

OTOH, it'd suit the current situation OK, and I imagine it'd be technically fairly easy to implement.

[yvi]

if a version/patch-level of DW

I suppose that's really not easy to determine. Other than actually talking to site administrator and making a whitelist I can't see how it is possible for us to check what version of a specific code-part other sites are using.

Anyone know whether that's even possible?

[pseudomonas]

This proposal suggests that when DW-based-sites are requesting content, they advertise their version in the request.

[yvi]

How do you define a version? Should it be changed every time a new security patch is uploaded? But other sites might not even pick up the code that introduces the security problems, so how can those be handled?

[pseudomonas]

Version would change with patches. There are various apps that have version strings that include arbitrary plugins and so on for non-standard options.

[phoenixsong]

In theory, I like the concept. In practice, I have no idea how reasonable it would be to execute/maintain.

[triadruid]

This. I don't think it's practical, or even really all that useful, since it's more full of holes than a block of Gruyere.

[ex_ranger990]

Seem flimsy. The bad guys could just lie about their version.

[sophie]

You're assuming that the people in control of the code are the bad guys. That's most likely not going to be the case - the bad guys in this instance are users of a site that's running a known-bad version, and who exploit a hole. In this case, unless the hole is *extremely* deep and allows someone to change the headers to change the version, it's likely to be the case that this solution is all that's needed.

Of course, the main thing this refers to hasn't been implemented yet - cross-site reading on friends pages - so it's mostly academic right now.

[ex_ranger990]

In matters of security, it is unwise to design for "not likely to happen". That's how Windows XP (pre-SP2) ended up with so many viruses and malware.

[zarhooie]

I like this in theory but I don't think there is any plausible or reasonable execution plan.

[birguslatro]

It'd be good to have the code in place for when DW might need it. But pro-actively trying to determine if other sites are in bad shape seems a waste of energy. Sites with up-to-date and legit code could still be a risk - it'd just need an admin with global access there to be evil and they can do anything their users can do.

[sophie]

If a site admin with that much access is evil, they probably already have access to the entire database, which means they already have information about saved authentication details for crossposting, which means they can log into those sites.

Protecting access from a rogue admin who has access to that much information is probably not worthwhile. This is for the case where the bad guys are users of a site that happens to have an exploitable bug - which definitely *is* worthwhile.

[cesy]

A system for temporarily blacklisting a certain site (whether DW clone or OpenID) and treating users from there as not logged in (so they don't see secure entries) could be very useful in the event of a security breach or unpatched hole.

Deciding which sites to blacklist could be much more tricky, and is probably best left to DW admins on a case-by-case basis, as they can talk to the other site's admins, investigate properly, or just slap a temporary ban on if there's something worrying or they hear about an attack or whatever.