Message-Id: <20081008115845.28E9AD0331@smtp.hushmail.com>
Date: Wed, 08 Oct 2008 11:58:40 +0000
From: "destiny" <destiny@...h.ai>
To: full-disclosure@...ts.grok.org.uk, kent@...eeriversinstitute.org,
	chomsky@....edu, marcio.barbado@...il.com
Subject: Re: What Lexical Analysis Became in The Web-Slave
	New World

hello friends

this email too long
i did not read it

On Tue, 07 Oct 2008 17:30:38 +0000 "M.B.Jr." 
<marcio.barbado@...il.com> wrote:
>What Lexical Analysis Became in The Web-Slave New World
>
>
>The point here is XSS, but rather than talking about the Internet
>weaknesses it exposes, this text goes against the poor algorithms
>being used to "detect" and/or avoid it.
>Hazardous XSS. Hazardous low-quality-XSS-filtering. These are 
>critical
>times for Internet users, undoubtedly. We face negligence‑oriented
>services at each new click.
>
>It's a contradiction seeing so many efforts (RFCs) being made and
>concomitantly, the only "user-friendly" (oh yeah, that expression)
>place offered by the industry to regular end users, remaining the 
>same
>application layer, the top of the iceberg.
>But regular end users don't know that. Paraphrasing Josh Homme, 
>they
>just "go with the flow", victimized by a doctrine that makes them
>believe those practices and technologies are the only ones 
>available,
>this way forming the new industry‑led slave mass. And it becomes a
>severer issue by the moment one realizes this commercially called 
>"Web
>2.0" and its risks disclose, more than vulnerabilities, web apps
>programming laziness, also known as XP or Agile methodology. Hail,
>Kent Beck!
>One way or another, a jungle presents itself to users, into the
>highest layer and preoccupations rise faster as indolent techniques
>are applied to XSS‑filtering.
>So, let's discuss it.
>
>You know Google? Well, check this out, there's this Google 
>corporation
>stating that their BETA releases represent a new web-based BETA
>concept. As if their web apps weren't client-server software.
>Two of their free BETA services, Google Calendar and Orkut, are 
>going
>to be discussed here along with an eager-to-follow-bad-examples
>Brazilian company, Locaweb, and its paid web-based e-mail service,
>Locamail.
>The worst case to be analyzed implies using the combination "<>"
>without quotation marks, to delimit some information. The referred
>services' handling for those characters can cause users' data to be
>lost.
>Readers will be able to test it, easily, at least on Google's 
>services.
>
>In opposition to the once vulnerable Google Documents, which was 
>used
>to accept html tags, Google Calendar, Orkut and Locamail simply
>discard anything which might resemble a tag. Their input analysis 
>is
>like:
>
>"Oh, did you see that less-than character and that other greater-
>than,
>ten lines below? Trim'em. Oh, wait! I just had a better idea. 
>Delete
>them and all the content they enclose as well. I'm one helluva
>genius!"
>
>What is worst? A cross-site scripting attack or an "Extreme
>Programming" team deploying such simple anti‑XSS mechanisms?
>
>Why spending time writing cautious lexical analysis algorithms? Why
>struggle seeking and/or trying to forecast specific hazardous 
>strings?
>Is it laziness? Perhaps Google doesn't have processing grid guts 
>for such:
>
>http://blog.managednetworks.co.uk/it-support/googles-20-petabytes/
>
>Not yet.
>At least for Google, it seems like some sort of indolence-guided
>programming technique, indeed.
>
>Specifically on Google Calendar, now. It has two basic views. A 
>broad
>view of one's schedule and an event‑specific view. The latter is 
>where
>one goes for inputting, say, a meeting's prior points to be 
>discussed.
>Let's start with its lighter problems. Incoherent 
>functions/methods.
>When one's in there, scheduling something means creating an 
>"Event".
>By the time one creates an "Event", he's given the option to name 
>that
>"Event", like a reminder which will appear in the broader view. If
>that event's name finishes with a semicolon, this character's 
>simply
>trimmed. Hey! That's bad for a start, isn't that?
>The incoherency comes with the algorithm which edits an already 
>created "Event".
>
>PoC-1: creating an "Event" and editing the "What" field
>When creating an "Event", if one writes something to the "What:" 
>field
>and finishes his writing with a semicolon, this last character will
>disappear by the time the "Create Event" button is activated.
>
>Example:
>
>  know your enemy;
>
>becomes
>
>  know your enemy
>
>then, the event is already created, the semicolon is lost and if 
>one
>corrects (edits) it, adding the disappeared semicolon again in the
>"What" field, and saves it:
>
>  know your enemy;
>
>there you go, incoherent XP; this time the semicolon remains 
>intact.
>
>Well, let's go for it. The worst case.
>
>PoC-2: "less-than" and "greater-than" delimiting information
>Though, let's continue playing in this very same situation.
>Suppose one encloses his Event's name between less‑than and
>greater‑than characters:
>
>  <know your enemy;>
>
>This time, clicking the "Save" button is going to send them all to
>hell. All is lost.
>
>In the "event-specific" view, there's this "Description" field for 
>one
>to put associated details. It's really nice to emphasize Google
>Calendar's behavior when a user saves that sort of content in the
>specific view. By the time he clicks the "Save" button, the web app
>automatically switches for the "broad" view, stating that the 
>user's
>stuff was saved:
>
>"Your event was updated."
>
>
>Everything looks pretty fine.
>Bad Google! That is so nasty because as matter of fact, sometimes
>stuff gets lost without even an advisory. A deceiving trap which 
>will
>cause the user to get confident about the integrity of some
>information that doesn't exist anymore. And time to act on data 
>loss
>situations matters.
>
>Putting it simple:
>if some information is put inside inequality signs in the
>"Description" field, clicking the "Save" button will apparently
>produce a regular behavior.
>Apparently I wrote, because nothing will be saved.
>It doesn't matter if your input is:
>
>  <parameter>
>
>or
>
>  <parameter with spaces in the same line>
>
>or even
>
>  <parameter with spaces
>  and newline>
>
>Trying to save it will cause all of it (characters and information
>involved) to be lost.
>
>Obs.: concerning this last PoC, the same problem applies to some
>fields within Orkut and Locamail.
>
>Real world example:
>suppose a Unix/Linux researcher's also a Google Calendar user 
>(!!!).
>What the hell, if he likes unstable, testing and evaluation 
>packages,
>why not using third party BETA applications?
>Continuing, let's say he scheduled a meeting for the next day in 
>order
>to debate some man pages alterations he wants to propose.
>Even though he has the original text files backed up in his lab, he
>chooses to paste their content into Google Calendar's "Description"
>field.
>His drafts, as expected, present some XML tags and some parameters
>enclosed by "<" and ">".
>By the time he saves his "Event" creation and/or changes, 
>everything
>looks normal but Google Calendar simply gets rid of tags and
>parameters enclosed by less‑than and greater‑than characters. They 
>all
>simply disappear without the researcher's acknowledgement.
>In the following morning, the researcher decides to save another
>thing, his time, printing that event's content at home before going
>directly to the meeting.
>Yeah, right. Print what?
>
>I wonder what Google would say about it:
>
>"... That's correct, if specific characters are used in specific 
>conditions..."
>
>Well, what to do? Their BETA concept is different from the world's.
>
>So, users of Google Calendar, Orkut and/or Brazilian web-based 
>Locamail, beware!
>Your worries now must reside enclosed by inequality signs.
>One philosophical and profound advice of a potential catastrophe.
>
>
>
>
>
>-- 
>Marcio Barbado, Jr.
>
>
>
>"And if any Agile methodology shall combine itself with BETA 
>releases,
>men are screwed."
>Revelations 22:22
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/

--
Burn fat. Finally, a diet plan that works.
http://tagline.hushmail.com/fc/Ioyw6h4exb2ohwLphyH26Kd4Qb6MAguEtRiIIbNSejjdQvk2GNTc7m/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists