Post Reply 
Sneaky Submits
Jul. 19, 2005, 07:53 AM
Post: #1
Sneaky Submits
Hi all

Ok, I really hate this.

I'm reading an article at reuters, and I click the "Next" button to goto page 2. Firefox pops a warning about submiting info thats not encrypted. I'm a bit suspicious but I click ok.

I check my log window and notice the following:

Code:
+++GET 399+++
POST /news/newsArticle.aspx?type=topNews&storyID=2005-07-18T232516Z_01_N18274057_RTRIDST_0_NEWS-BUSH-LEAK-DC.XML HTTP/1.1
Host: today.reuters.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050718 Firefox/1.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://today.reuters.com/news/newsArticle.aspx?type=topNews&storyID=2005-07-18T232516Z_01_N18274057_RTRIDST_0_NEWS-BUSH-LEAK-DC.XML
Content-Type: application/x-www-form-urlencoded
Content-Length: 5051
Posting 5051 bytes...


"Posting 5051 bytes...", give me a break. It seems a bit much to get to the "Next" page.

Viewing the posted info, didn't really help determine what they were posting, since most of the data was encoded and looked like jiberish.

Reading what they (laughingly) call a "privacy policy", doesn't fill one with confidence.


Anyway, I'm thinking a new filter is needed for cases like this, since thats not the only site I've seen this on.

What I have in mind is intercepting "onsubmit" and have a window/dialog box popup & show what is being posted (unencoded) if the content-length is excessive, say 128 bytes for starters. If I don't like what I see, kill it, otherwise let it through.


Does this seem doable, or will it be an exercise in futility?

Any comments, suggestions, ideas, or code would be welcome.

Mike
Add Thank You Quote this message in a reply
Jul. 19, 2005, 08:52 AM
Post: #2
 
It's nothing scary. The posted gibberish is the text of page 1 base64-encoded. Probably an awkward way to tell the script where to continue with page 2.

Interception should be possible by looking at the length of the individual input values. If you like "push button" games, you'll probably have a good exercise with such a filter. Smile!

Seriously, onsubmit is indeed misused. I've seen pages that auto-submitted data to a bunch of "gimme your email" forms. But most of the time it's needed to keep the thing going, especially on sites that rely on dynamic content.

sidki
Add Thank You Quote this message in a reply
Jul. 19, 2005, 11:56 AM
Post: #3
 
Well it scared me and I ain't afraid of nothin. Smile!

No, seriously, I figured that it was the page content, but that still bugs me.
I don't want to reveal my tweaks to them. Smile!

I had another idea, but I'm not sure if it would work.

Intead of intercepting "onsubmit", redirect to a local.ptron html page when theres an outbound "content-length" header > x.

This way, I wouldn't be trying to cram the data into a popup/dialog. Also, I wouldn't have to inject special scripts into every web page.

What I'm not sure about is how/if the browser would "see" the posted info.

Any thoughts on this?

Mike
Add Thank You Quote this message in a reply
Jul. 19, 2005, 12:51 PM
Post: #4
 
Well, technically you can $RDIR (but not $JUMP) a POST.
The browser probably doesn't care either.

The question is what should the local.ptron document do with the posted data?
I would think that you need a Perl (or similar) enabled local server to *handle* the POST in the first place, and to provide the extensions for inspecting the data and sending them to the original destination after approval.

sidki
Add Thank You Quote this message in a reply
Jul. 19, 2005, 03:43 PM
Post: #5
 
Well, I wondered if the posted data could be seen after the redirect via the dom.

If not, it wouldn't be worth the hassle, otherwise it could work.

Pass the original url as a query to the redirect, do stuff, submit back to the original url.

I guess I'll give $RDIR a try and see what happens.

Mike
Add Thank You Quote this message in a reply
Jul. 20, 2005, 09:54 AM
Post: #6
 
Well, you can't see any of the posted data after the $RDIR. I figured it was worth a shot.

Also, after browsing around a bit, decoding the posted data might be an issue too, without knowing how it was encoded.

So I think I'm going to scrap this idea, step back and rethink it.

Mike
Add Thank You Quote this message in a reply
Jul. 20, 2005, 10:28 AM
Post: #7
 
z12 Wrote:I figured it was worth a shot.
True, but that was the likely case. I think Prox - now acting as a server - doesn't know what to do with a POST request, and is interpreting it as a GET instead (i didn't test that).

sidki
Add Thank You Quote this message in a reply
Post Reply 


Forum Jump: