IMHO things like Dropbox and Google Disk (aka Docs) are just steps towards a web or cloud filesystem.
Frustrated by the deficiencies of to-do list and organizer apps, I am playing around with just using files - on one of these nascent cloud filesystems. Perhaps edited by hand. (Hey, emacs runs on my android pda-like device, but I haven't tried org-mode.) Perhaps with a nicer front end.
Frustrated because I really need the ability to do offine editing on my PDA. Google Disk only allows offline viewing. Dropbox... unclear... certainly allows files to be queued for upload when offline... but the first few text editors I tried just lose the data when you try to edit offline, and then save (of course, so many don't have an explicit save).
Perhaps I'll cobble something together with git or mercurial. After all, DVCS is just a Pootr Man's occasionally connected wide area network filesystem.
But, the above is just background to my post.
As I play around with Dropbox and Google Disk, I am
1) happy to see how easy they have made it to share things. Share is a button as prominent as "Save File" used to be.
2) scared at how easy they have made it to share things by accident. I have several times hit Share by accident. (Especially since Google Chrome has oscillatory layout issues - buttons keep jumping around.) In another app, MapMyHike, every time I save I am asked if I want my record to be private or public. Doesn't seem to be a default setting so that I can disable the Public option. Several times I have saved as public by accident. (I should not need to have to explain the security issues with recording your hikes publicly accessible.)
But more... playing around with Dropbox and Google Drive synching and offline access:
It occurs to me that permissions need to be not just by user. Not just by user/role (as I have discussed elsewhere). But also by user and locale, by user and device.
I.e. there is some stuff that I may want to have on a cloud filesystem that I may never want to have on my phone or PDA.
There is some stuff that I may want to have on a cloud filesystem, that I may want to access on my phonbe or PDA, but that I may never want to have cached or enabled for offline access.
This is, I suppose, just a role. But instead of having to manage many roles, I might just want to say "Never save this file offline on a phone or PDA". Simple.
Hmmm.... I want to say that this is just a capability. But it isn't, is it? It is rather like a capability modifier, something associated with the data, not the user.
In some ways, it is an application of DRM, except for the benefit of the user, not just the motion picture industry.
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Tuesday, September 18, 2012
Thursday, December 08, 2011
A Modest 1 bit Proposal about Quotification - making the Default Easy
Listening to an old "Security Now" podcast while doing my morning stretches.
Leo Laporte's TWIT website was hacked, and Steve Gibson, the Security Guy, says "Any time you are soliciting user input, there is a risk of malicious input somehow tricking the backend and executing that input, when it is meant to be, you know, benign [input data, like] user name and password.".
This is typical of the classic SQL injection hack, and, indeed, of any hack where the attacker is able to inject scripting code and fool the backend into executing it. Typically by embedding quotes or the like in the input string.
(For that matter, Steve's description also applies to binary injection via buffer overflow. But we won't go there; this page will talk only about non-buffer-overflow attacks, sijnce we have elsewhere described our agenda for preventing buffer overflow attacks.)
Say that you are talking user input like NAME, and are somehow using it to create an SQL or other language command, like "SELECT FIELDLIST FROM TABLE WHERE NAME = '$NAME' ". But now the attacker, instead of providing a nicely formed string like "John Doe", provides instead something like "anything' OR 'x' = 'x ". (I added spaces between the single and double quotes for readability.) I.e. the user provides a string that contains quotes in the target language - not the language where the query string is composed, but a language further along. So the query string becomes "SELECT FIELDLIST FROM TABLE WHERE NAME = 'anything' OR 'x' = 'x' ". And now the query matches any row in the table. (http://www.unixwiz.net/techtips/sql-injection.html provides examples, as does wikip[edia.).
The general solution to this is "quotification": take the user input, and either delete or quote anything that looks like a quote in the target language:. E.g. transform the attacker's string "anything' OR 'x' = 'x " into either "anything OR x = x " or "anything\' OR \'x\' = \'x ".
The problem with deleting stuff from the user string is that sometimes the user is supposed to have quotelike things. Consider names like "O'Toole". Or consider prioviding, e.g. via cut and paste, Chinese unicode names in an application whose original programmer was English, but where the system is otherwise capable of displaying Chinese. It is a pity if the barrier to internationalizaion is the "security" code scattered throughout your application that santizes user input. Worse, that is the sort of code that might get fixed by somebody who fixing internationalization problems who doesn't understand the security issues
The problem with quotifiying stuff is that it is hard. It is not just a case, for you Perl afficionadoes, of doing s/'/\/g - what about input strings that already have \\' inside them? And so on.
But the real problem, applicable to both deleting and quotification strategies, is that the code doing the user input sanitization does not necessarily know the syntax of all of the languages downstream. It may know that there is SQL along the way - but it may not know that somebody has just added a special filter that looks for French quotes, << and >>. Etc. Not just special symbols: I have defined sublanguages where QuOtE and EnDqUoTe were the quotes.
The security code may know the syntax at the time the sanitization code was written. But the downstream processing may have changed. The syntax of the language may have been extended, in a new revision of the SQL or Perl or ... . (I found a bug like that last year.)
The problem is that the user input santization code is trying to transform user input from strings that may be unsafe, to strings that are guaranteed to be safe forever and ever, no matter what revisions are made to the language, etc. The problem is that the default for character strings is that ANY CHARCATER MAY BE PART OF A COMMAND unless specially quoted.
We need to change this default. Here is my moldest proposal:
Let us define a character set whereby there is a special bit free in all characters. And whereby, if that special bit is set, it is guaranteed by ANY REASONABLE LANGUAGE that no character with that special bit set will be part of any command or language syntax like a quote symbol.
We should strongly suggest, that the visual display for the characters with and without the special bit set is the same. Or at least, the same in most situations - in others you may want to distinguish them, e.g., by shading.
.
If you are using something like BNF to describe your language, then it might be:
ORDINARY_CHARACTER ::== 'A' | 'B' | ...
TAINTED_CHARACTER ::== 1'A' | 1'B' | ...
POSSIBLY_TAINTED_CHARACTER ::= ORDINARY_CHARACTER | TAINTED_CHARACTER
where I am using the syntax 1'A' to describe a single character literal. with the special bit set.
STRING_LITERAL := QUOTED_STRING | TAINTED_STRING
TAINTED_STRING ::= TAINTED_CHARACTER+
QUOTED_STRING ::= " CHARACTER* "
(Actually, I am not sure whether a quoted string should be the abnove, or
QUOTED_STRING ::= " POSSIBLY_TAINTED_CHARACTER* "
)
Leo Laporte's TWIT website was hacked, and Steve Gibson, the Security Guy, says "Any time you are soliciting user input, there is a risk of malicious input somehow tricking the backend and executing that input, when it is meant to be, you know, benign [input data, like] user name and password.".
This is typical of the classic SQL injection hack, and, indeed, of any hack where the attacker is able to inject scripting code and fool the backend into executing it. Typically by embedding quotes or the like in the input string.
(For that matter, Steve's description also applies to binary injection via buffer overflow. But we won't go there; this page will talk only about non-buffer-overflow attacks, sijnce we have elsewhere described our agenda for preventing buffer overflow attacks.)
Say that you are talking user input like NAME, and are somehow using it to create an SQL or other language command, like "SELECT FIELDLIST FROM TABLE WHERE NAME = '$NAME' ". But now the attacker, instead of providing a nicely formed string like "John Doe", provides instead something like "anything' OR 'x' = 'x ". (I added spaces between the single and double quotes for readability.) I.e. the user provides a string that contains quotes in the target language - not the language where the query string is composed, but a language further along. So the query string becomes "SELECT FIELDLIST FROM TABLE WHERE NAME = 'anything' OR 'x' = 'x' ". And now the query matches any row in the table. (http://www.unixwiz.net/techtips/sql-injection.html provides examples, as does wikip[edia.).
The general solution to this is "quotification": take the user input, and either delete or quote anything that looks like a quote in the target language:. E.g. transform the attacker's string "anything' OR 'x' = 'x " into either "anything OR x = x " or "anything\' OR \'x\' = \'x ".
The problem with deleting stuff from the user string is that sometimes the user is supposed to have quotelike things. Consider names like "O'Toole". Or consider prioviding, e.g. via cut and paste, Chinese unicode names in an application whose original programmer was English, but where the system is otherwise capable of displaying Chinese. It is a pity if the barrier to internationalizaion is the "security" code scattered throughout your application that santizes user input. Worse, that is the sort of code that might get fixed by somebody who fixing internationalization problems who doesn't understand the security issues
The problem with quotifiying stuff is that it is hard. It is not just a case, for you Perl afficionadoes, of doing s/'/\/g - what about input strings that already have \\' inside them? And so on.
But the real problem, applicable to both deleting and quotification strategies, is that the code doing the user input sanitization does not necessarily know the syntax of all of the languages downstream. It may know that there is SQL along the way - but it may not know that somebody has just added a special filter that looks for French quotes, << and >>. Etc. Not just special symbols: I have defined sublanguages where QuOtE and EnDqUoTe were the quotes.
The security code may know the syntax at the time the sanitization code was written. But the downstream processing may have changed. The syntax of the language may have been extended, in a new revision of the SQL or Perl or ... . (I found a bug like that last year.)
The problem is that the user input santization code is trying to transform user input from strings that may be unsafe, to strings that are guaranteed to be safe forever and ever, no matter what revisions are made to the language, etc. The problem is that the default for character strings is that ANY CHARCATER MAY BE PART OF A COMMAND unless specially quoted.
We need to change this default. Here is my moldest proposal:
Let us define a character set whereby there is a special bit free in all characters. And whereby, if that special bit is set, it is guaranteed by ANY REASONABLE LANGUAGE that no character with that special bit set will be part of any command or language syntax like a quote symbol.
We should strongly suggest, that the visual display for the characters with and without the special bit set is the same. Or at least, the same in most situations - in others you may want to distinguish them, e.g., by shading.
.
If you are using something like BNF to describe your language, then it might be:
ORDINARY_CHARACTER ::== 'A' | 'B' | ...
TAINTED_CHARACTER ::== 1'A' | 1'B' | ...
POSSIBLY_TAINTED_CHARACTER ::= ORDINARY_CHARACTER | TAINTED_CHARACTER
where I am using the syntax 1'A' to describe a single character literal. with the special bit set.
STRING_LITERAL := QUOTED_STRING | TAINTED_STRING
TAINTED_STRING ::= TAINTED_CHARACTER+
QUOTED_STRING ::= " CHARACTER* "
(Actually, I am not sure whether a quoted string should be the abnove, or
QUOTED_STRING ::= " POSSIBLY_TAINTED_CHARACTER* "
)
And we require that the only place where the possibly tainted characters with the tainted bit set are ONLY permitted in strings. Nowhere else in the language. Not in keywords, symbols, operators....
Then we just have to ensure that all of our input routines set the special bit. If you really need to form operators, the programmer can untaint the data expliocitly. Btter to have to untaint explicitly in a few p[laces, than to have to quotify correctly in all places.
Perhaps better to make taintimg the default. To flip the polarity of the special bit. And to require that language syntax, keywords, etcv., be set only if the special bit is set.
This is just the well known taint or poison propagation strategy. Exposed to programming language syntax definitions.
I have elsewhere espoused taking advantage of extensible XML syntax for programming languages. This is similar, although orthogonal.
- wi8ki'ed at http://wiki.andy.glew.ca/wiki/A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy
- as well as posted on my blog
Wednesday, July 15, 2009
Calendars and Phones
A friend just got an iPhone. Primary uses, apart from as a cell phone and music player: PDA stuff like calendaring.
Now she keeps her calendar on her iPhone. Both personal/family, and work related.
Her employer uses Outlook Exchange Calendaring. But they do not allow calendars to be synchronized with personal calendars outside of work. So my friend simply does not use the company calendar. She says that co-workers complain, when they arrange meetings with her that appear to be free on her company calendar, which is empty, but which she cannot make because of conflicts. But she says that is so much more important to her to be able to manage her personal and family life in the same place as her work meetings, that she is willing to put up with the loss of the shared work calendar.
Perhaps I should mention that she works, not exactly part-time, but very flexible hours. She is constantly managing family commitments, getting kids to events, as well as weekend and evening work assignments. Her day is not neatly partitioned into work and non-work.
MORAL:
Now she keeps her calendar on her iPhone. Both personal/family, and work related.
Her employer uses Outlook Exchange Calendaring. But they do not allow calendars to be synchronized with personal calendars outside of work. So my friend simply does not use the company calendar. She says that co-workers complain, when they arrange meetings with her that appear to be free on her company calendar, which is empty, but which she cannot make because of conflicts. But she says that is so much more important to her to be able to manage her personal and family life in the same place as her work meetings, that she is willing to put up with the loss of the shared work calendar.
Perhaps I should mention that she works, not exactly part-time, but very flexible hours. She is constantly managing family commitments, getting kids to events, as well as weekend and evening work assignments. Her day is not neatly partitioned into work and non-work.
MORAL:
- People want both personal and work calendars on their devices like phones.
- Corporate security rules get in the way.
Wednesday, January 07, 2009
> 5 hours to do a Software Update
It's been one of those days. Sob stories about time wasted in virus scanning and software updates are my specialty, aren't they?
Some people write about what they KNOW.
I write about what ANNOYS ME.
---
I left for work circa 8am. A bit late, considering that I started leaving at 7:30am, but that's another story.
I had not driven a mile before a realized I had forgotten something. I returned to the house.
I thought: "Since I am delayed, maybe I should just check my computer? It should be fast."
That's how it always goes. It was 8:20.
As soon as my computer boots, the security center red alert is there. Update the virus scanner. Update Windows. Oh-oh: it's a big update. SP3. Apparently I have not used this personal computer for a while.
Before long both my personal computer, and my company laptop, are consumed doing updates. Worse, I could not get anything else done on the net on any other computer (I have several), since my home broadband is slow.
I did not want to disturb the update process - that has, in the past, occasionally resulted in brokennesses. So I waited. And waited. And WAITED. After a while it becomes a matter of interest: how long will this take?
I have been able to use my work laptop for a while. My 3 year old work laptop updated faster than my 6 year old low-end personal tablet PC.
Is this the new benchmark: how long does it take to do a big software update?
It's now 13:53. The personal computer has just rebooted after the update. I hope it's finished, but I don't know yet.
Some people write about what they KNOW.
I write about what ANNOYS ME.
---
I left for work circa 8am. A bit late, considering that I started leaving at 7:30am, but that's another story.
I had not driven a mile before a realized I had forgotten something. I returned to the house.
I thought: "Since I am delayed, maybe I should just check my computer? It should be fast."
That's how it always goes. It was 8:20.
As soon as my computer boots, the security center red alert is there. Update the virus scanner. Update Windows. Oh-oh: it's a big update. SP3. Apparently I have not used this personal computer for a while.
Before long both my personal computer, and my company laptop, are consumed doing updates. Worse, I could not get anything else done on the net on any other computer (I have several), since my home broadband is slow.
I did not want to disturb the update process - that has, in the past, occasionally resulted in brokennesses. So I waited. And waited. And WAITED. After a while it becomes a matter of interest: how long will this take?
I have been able to use my work laptop for a while. My 3 year old work laptop updated faster than my 6 year old low-end personal tablet PC.
Is this the new benchmark: how long does it take to do a big software update?
It's now 13:53. The personal computer has just rebooted after the update. I hope it's finished, but I don't know yet.
Saturday, December 27, 2008
Financial websites - why not read-only access?
I've been thinking about switching from Quicken on my PC, to a web-based financial tracking site.
Something like
Something like
- Quicken Online - lousy features compared to Quicken PC, mainly for beginners
- Yodlee MoneyCenter
- Mint - apparently professional, but a bit fascist, doesn't make it easy to have user defined categories
- Wesabe - emphasizing social networking
There are many, many, others.
Motivation:
- I have too many computers. I want o be able to access from work, and from home, and from my phone, and...
- I'm tired of having to re-set things up when I switch PCs. And, no, the migration tool seldom works, usually because I can't power up the dead machine to migrate from.
- I want my wife and I to be able to simultaneously access
- Basically, I have just about given up on having a personal computer. Or is that "a single personal computer". If my company IT allowed me to use my personal machine at work, then maybe; but they don't, so I am being pushed away from the PC-centric model to the web-centric model.
The security implications are scary: one website, with access to all of your passwords and accounts for other financial websites.
Wesabe makes a point of its security model: apparently they store the passwords, etc., on your PC, and never put the passwords onto their server. I imagine they run some client side code that accesses your other financial sites, and then filters it to upload to Wesabe.
- But, then Wesabe may not allow the sort of ubiquitous access I desire. Does it?
Mint emphasizes that their access to your financial data is read-only. They also emphasize that the actual passwords, etc., are stored. not at the Mint site, but at Yodlee - which apparently provides such services to many banks already.
- One poster points out that this is all well and good, but if the hacker is inside Mint or Yodlee, then... Well, this poster says that they should at least be bonded to indeminfy the user against that risk.
- Wesabe says the developed their own screen-scraping approach to accessing finanicial websites, in part to allow them to be free as long as possible, and not to have to pay fees to Yodlee.
OK, okay, so security is an issue.
So, the thought occurs to me: why can't I give this "aggregating" sites like Mint and Wesabe read-only access to my other financial websites? Read-only access to my bank, my 401K, etc.?
Most of the things that I want to do on such a site are read-only - track my investments, look at my asset allocation and ensure that it is balanced across all of my investment accounts at different sites, etc.
I'm reasonably happy NOT to be allowed to make changes to my investments from the central site - to have to log in to my stockbroker or 401K site separately.
Sure, even read-only access to my various fnancial account websites would be a treasure trove for the ID thief. Account numbers, maybe even SSNs (although one might hope those could be filtered out). Things that a social engineering attacker could use on the customer support phone line. Nevertheless, such read-only access would be a lot less risky than allowing read-write access, with the ability to change mailing addresses, etc.
Trouble is, all of my financial services web.accounts give me one account login, and one password, that provides full access to the entire account.
It seems that this could be changed... Let's start writing letters...
---
This is just yet another example of the Principle of Least Privilege. Of how it should be possible to split a particular security role into smaller pieces.
Subscribe to:
Posts (Atom)