Apr. 13th, 2009

haggholm: (Default)

Someone on a forum did me the distinct disfavour of posting the first 20 minutes of the trainwreck film, The Secret, where the “secret” refers to the “Law of Attraction”. Briefly, the idea is that thinking about things will cause them to come about—think about the bad things in life and bad things will happen to you; think about good things and they will happen instead. I’m not going to waste time and space talking about why this is preposterous. What motivates me to write this is rather my anger at this, and what I consider to be the harmful consequences.

Lots of people actually seem to believe in this crap. To some extent, that isn’t too surprising. The facile reasons are, first, that it certainly fits in with a lot of New Age magic; second, that the testimonials look good (the happy supporters they choose to speak out really are happy—of course they are, living in $4.5 million mansions…); and third, it is endorsed by highly visible and respected idiots, like Oprah.

More importantly, however, it ties in very neatly with things that are actually true.¹ Of course positive thinking tends to improve your life in many ways—it’s a well established psychological fact that acting happy tends to make you happier; happiness and confidence improve your interpersonal skills and relations; avoiding focusing on negative things frees you from brooding over misfortunes. None of this validates the “secret”. The fact that your mental attitude is connected to your mental state is painfully obvious, and a positive demeanour improving interpersonal relations (and through that avenue, your life) is only evidence that people respond better to happy, confident people than to sad or aggressive ones, and does not require the existence of some mysterious universal energy found by viciously abusing quantum physics.

All right, then, some hypothetical person might ask, what is the harm? It may be silly, but if it motivates people to engage in positive thinking, which you freely acknowledge is a good thing, then why should we discourage this stuff?

Apart from the fact that I am as dedicated as I am able to pursue truth, and consider it morally valuable in its own right, I do think that this silliness has a very sinister side.

The first and most obvious problem is that when people put their trust in anything that doesn’t actually work, there is a risk that they will eschew real, working solutions because they think they already have one. For instance, the 20-minute clip from The Secret has someone claiming: I’ve seen cancer dissolved.

Let me reiterate that. The Secret strongly implies that positive thinking can cure cancer.

That is when it ceases to be funny. People who swallow this whole are lead to believe that positive thinking suffices to cure cancer. This misinformation can kill. Nothing cures cancer like surgical steel (preferably with chemotherapy and/or radiation therapy as adjuvant therapies to prevent recurrence). Failing to seek proper help can kill you, painfully and horribly.

And, of course, we can extrapolate this to any other medical condition, or for that matter, any other problem.

The second repugnant consequence of this belief in the “Law of Attraction” is that while the film-makers focus strongly on the empowering effect, when positive thinking is believed to change your life, the explicit corollary is that negative thoughts lead to bad things happening. They make this very clear: These people assert not only that negative things will make bad things happen, but that whenever bad things keep happening to you, it is because you are thinking negative thoughts. It’s under your control, they say, and you have the power to change it—but if events are bad, you caused them to happen.

We know, of course, that this is bunk. However, those who believe it are also made to believe that all their misfortunes are their fault. If your house burned down, if you developed cancer, if you were raped—according to the makers of The Secret, this is your fault: You made it happen. This is not only nonsensical, it is also an extremely cruel thing to allege.


¹ There is a parallel here to the view of some bloggers, such as “Orac”, of “complementary and alternative medicine”, which are perceived to usurp some actually valid ideas, like nutrition and exercise: CAM practitioners prescribe good nutrition, exercise, and homeopathic remedies; good nutrition and exercise are clearly good for your health; therefore homeopathy must be good—stated so baldly, the intellectual bankrupcy of the notion is obvious.

haggholm: (Default)

Since I’m rewriting the framework behind my website, and since the new framework has a lot more dynamic features to go with some other projects of mine (petterhaggholm.net is pretty static), security has been on my mind, especially as I will have a login system. Of course I started with the basics: Require a session token for every action; make sure the session token is nice and secure (it’s a big hash involving a random number); make the cookies HttpOnly… (HttpOnly cookies can’t be read or set with Javascript, so malicious scripts cannot steal these cookies. They are only present in request headers.)

The problem

CSRF means that cookies alone aren’t safe, however. If you write this sort of code and don’t know what CSRFs are, I recommend you read this very good article. The very brief version of a simple example:

  • Whenever you request a resource (e.g. via GET or POST, your browser checks if it has servers matching the server.
  • If the browser has any such cookies cached, it sends them in the request header (Cookie: whatever).
  • Not only pages are requested via GET; other resources, like images, are as well.
  • The browser doesn’t keep track of what tab or window the request comes from. (I’d be annoyed if it did, since I’d lose my session data if I opened the same site in a second tab, or closed and re-opened.)

Now suppose that your webapp has an action tied to a GET request (you shouldn’t), or is a PHP app that uses the $_REQUEST superglobal without checking if it is GET or POST. Maybe there’s a Delete button on a form that works by making an AJAX call (or plain form submission) to foopage.php?action=delete. What happens if I, on some entirely different website, create a page as such:

<img src="http://www.yoursite.com/images/pretty.jpg" title="A pretty picture" />
<img src="http://www.yoursite.com/foopage.php?action=delete" title="Another pretty picture" />

Well, your browser will parse the page source, and will issue a GET request for each image src in order to display all the picture. The Cookie: header will be issued with each request, because your browser will always issue that header when the request goes to the matching domain. This means that if the webapp relies solely on the cookie for authentication, it will think that you are issuing a delete command, and will happily go ahead and do whatever it is that deletion does.

My problem with the usual solution

There is a canonical solution to this problem. (Always using POST rather than GET isn’t it—that’s a good idea, but POST requests can be forged, too.) This solution is to include a unique token in every form on generated pages; so if you request a form from secureapp.com, it might contain something like

<input type="hidden" name="secure_token" value="384729348923498" />

Ideally, this token should

  1. Be unique to this form
  2. Expire in a reasonable amount of time

The advantage of this is that because this is embedded in the page, and not present in the headers, a request issued from a different page (such as with the XSRF attack described above), the information just isn’t available.

But that’s kind of a drag. For example, what if my page uses AJAX and doesn’t contain any forms? What if I have multiple tabs or windows open with the same site (as I often do, with many sites)?

I currently strike something of a compromise: A session has one such token (which isn’t nearly as good as unique tokens all over the place, but much better than none at all: It protects me against the simple cookie-based attack). I am currently working on a mechanism to generate better tokens when there are forms on the pages, but the simple token is used by default, and will probably continue to be used for AJAX requests that just don’t have forms to reference. My framework discards all POST data supplied by requests that have either a bad session key or a mismatched or missing “XSRF token”. GET variables are never used as “data”, but only as extra resource identifiers, e.g. picture.py?pic=foo.jpg.

But a single token does have serious weaknesses. If the attacker can retrieve even one page with the token embedded (e.g. via a malicious script that issues a GET request on the client’s behalf, or by stealing it from the cache, or some means that I have yet to take into consideration), the token is compromised, and we have already established that cookies are vulnerable.

An alternative?

One fairly obvious idea that occurs to me is that while it’s easy to hijack (but not steal!) cookies, and may be possible to steal the token, the information is not available simultaneously. The cookie is not visible to the attacker: This XSRF attack is based on the fact that he can make use of the cookie by tricking the client into issuing a request that will have the cookie attached, without the attacker ever needing to access it. By contrast, the token is jeopardised precisely because the attacker may see it. What I would like to do is combine the two, e.g. by requesting a hash of the cookie value and the token value.

It’s actually somewhat ironic: Normally, it is a truism in computer security that you cannot increase security by adding more data if all those data are vulnerable. Here, however, the data are vulnerable by different avenues, and what I want to do is raise the barrier by requiring an attacker to exploit both simultaneously.

Unfortunately, this idea isn’t workable in so simple a fashion, because, well, I made my cookies HttpOnly! This means I can’t use them to create hashes, no matter how nice it would be. In essence, what I want is a browser feature that doesn’t exist, where I can request a secure, one-way hash based on an otherwise unreadable cookie:

<input type="hidden" value="2487923984" hashwith="my_httponly_cookie" />

I think what I may do is set two cookies for my sessions: The primary session identifier, which remains HttpOnly to prevent anyone from stealing it; and a token cookie, included specifically for use by the page’s Javascript, AJAX requests, etc.


Internet security is a tricky and thorny issue. I find it difficult to know when I am tackling the real issues, and when I am just engaging in busywork. An awful lot of my promising ideas have turned out to be dead ends that either wouldn’t work at all (c.f. the hash above), aren’t at all secure, or just don’t add anything to the security I already have.

Thoughts?

Profile

haggholm: (Default)
Petter Häggholm

April 2016

S M T W T F S
      12
345 6789
10111213141516
17181920212223
24252627282930

Most Popular Tags