|
From: Ivan R. <iv...@we...> - 2006-08-17 19:49:30
|
Carles Bonamusa wrote: > > We've been also working on a first approach to comment removal. As far > as it goes we're having some issues trying to manage tricky situations where > non-standard markup can fool libxml and so fool our comment stripping code, > but for the very standard case this new feature is almost coded and tested. I can see how there will be many "modules" that will want to access the HTML output, either in the form of SAX events or as a DOM tree. Do you have any suggestions how to implement that? At the very least a module could say "I want a DOM tree of the response" or "Parse this page as HTML and send me the SAX events". That way there will be only one parser with data consumed by many modules > To send gathered data back to the serer there are two available ways, > one of them must be selected when writing form markup by using *method* > attribute to define submission method. When *GET* method is used, client > browser will build the request as a url based on form's *action* > attribute, appending successful controls name-value pairs as url > parameters. The other option is to use *POST* method. Using this, > /form-dataset/ containing control's name-value pairs is passed in the > body of the request instead of being chained that data to the request url. Yes, in a general case, the parameters can appear in both places at the same time (only for POST requests, obviously). > All previous flaws can be easily identified if some data about form > structure is stored when form is sent to the user. So the idea is to > filter outgoing html code issued by the back-end server searching for > form definitions. Whenever a form markup tag is found , then for every > submit button defined (which eventually means a different url for the > action attribute) a form-description block is build containing the > following data. Why do you want to build one block per submit button? A submit button as such does not guarantee that a different action attribute value will be used. I think you should build only one block per form. I understand that you need to bind the block to something. This is why I want to suggest to create a unique per-form token and to embed it into the form as a hidden field. This field will serve as a key to bind the form to. The key can be global or session specific. When a form is submitted: 1) If you see the token you know which form it belongs to. 2) If you don't see a token then you assume it's a CSRF attack :) > * A list of defined parameters (name, type, and size if one is > defined) > * A list of hidden fields and their respective preassigned values. > * For each select control, a list of its predefined available > options. > * submission method. > * action url. You also need to store the encoding method (e.g. multipart or not). > This data is then encrypted and sent to the user attached to the The performance would increase dramatically if you leave the data on the server. It would probably be a bit safer to. (No attacks against the encrypted content.) > corresponding form (it could be added as an additional hidden field, or > issued as a cookie). A hidden field is better. > In all the previous described process, it is assumed that the full form > definition is known when serving the page. That is, all form components > are defined by server side application. > > This scenario, although the most frequent, it is not the only one which > is possible. As you say, the proposed defence method is not foolproof. So my question is why do it? Wouldn't it be simpler to implement this type of functionality through application monitoring and construction of a dynamic positive-security model? The difference being you would not need to look at HTML for clues - you would be looking at the actual data, meaning this alternative approach would also form for forms constructed and changed from JavaScript. (Personally I would implement to per-form token thing as a defence against CSRF attacks.) -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall Apache Security (O'Reilly): http://www.apachesecurity.net |
