Date: Wed, 8 Oct 2008 12:00:50 -0300
From: M.B.Jr. <marcio.barbado@...il.com>
To: destiny <destiny@...h.ai>
Cc: full-disclosure@...ts.grok.org.uk, kent@...eeriversinstitute.org,
	chomsky@....edu
Subject: Re: What Lexical Analysis Became in The Web-Slave
	New World

Well you should if:

  * you are concerned with the awfully insecure programming
"methodologies" imposed by the industry and its productiveness thirst,
sadly being held as acceptable; and/or

  * you are a Google Calendar, Orkut and/or Locamail user.

If by one side, the industry induces Internet technologies consumers
(regular end users) to act solely via web browsers; by the other, it
forces programmers to adopt harmful techniques even for input lexical
analysis security algorithms, which is a PARADOX. And once more,
regular end users get damaged for that.


Yours faithfully,



On 10/8/08, destiny <destiny@...h.ai> wrote:
> 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/
>
> --
> Click to become a master chef, own a restaurant and make millions.
> http://tagline.hushmail.com/fc/Ioyw6h4eAFcOzq2tZfDuHEDaVLYvSgP8CWP6pBt4ca6pDQJ7n70JTo/
>
>


-- 
Marcio Barbado, Jr.
_______________________________________________
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