Adding an int64 upload identifier to NavigationEntry and ViewHostMsg_FrameNavigate_Params

[Chris Bentzel]

<Probably a small target audience, but decided to broadcast anyway>

To help solve crbug.com/55551 I need a way to extract the POST data identifier for the top-level frame. The full POST data is not needed.

It seems like there are three approaches for this:

  a) Unpack the existing content_state_ structure in the NavigationEntryImpl. Upside: this should introduce minimal changes to the codebase, provides the option to eventually crack out the POST body, and reduces redundant information. Downside: it's gross, and introduces webkit_glue dependencies into the browser-side portion of content. Up until now, that's been treated as an opaque string browser-side.

  b) Add an int64 UploadData identifier to NavigationEntryImpl and ViewHostMsg_FrameNavigate_Params. Upside: Pretty clean at call sites that care. Downside: redundant information is stored, all generators of ViewHostMsg_FrameNavigate_Params structures need to set two variables for the same thing.

  c) Add an IPC from browser->render where the browser can query about the UploadData identifier for a frame within a RenderView [and possibly just for the top-level RenderView only]. Upside: ?. Downside: Extra latency, extra complexity.

I have a local change which does b), but want to get some feedback before making it pretty and sending out for review.

[Charlie Reis]

I'd probably be in favor of (b) as well.  My concern with (a) is that it asks the browser to decode more state from the partially-untrusted renderer.  It would be nice not to put the browser process at risk if there's a bug in that decoding logic.

Charlie

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Chris Bentzel]

Thanks Charlie.

Your response brings up another point: do we have a trust model for the render processes? I'm sure there's plenty of places that we aren't doing as much input validation as we would for network requests.

[Charlie Reis]

It's discussed in http://seclab.stanford.edu/websec/chromium/, but I'm not sure there's a place in the code I could point you.

Carlos or Chris might be able to comment on the current validation we do on IPC messages.

Charlie

[Scott Violet]

I tend to favor (b) as it's not as obscure and less fragile. That
said, I don't have a strong opinion. I did want to mention that the
session restore code (not in content) does some cracking of the
content state. Specifically it calls to webkit_glue to remove form
data for posts before saving to disk.

-Scott

On Thu, Jan 26, 2012 at 9:26 AM, Chris Bentzel <cben...@chromium.org> wrote: