Thread: [Mod-security-developers] Proposal on html form protection [Second attempt]
Brought to you by:
victorhora,
zimmerletw
From: Carles B. <cbo...@is...> - 2006-07-27 10:11:32
Attachments:
ms-rfc-2.html
ms-rfc-2.txt
|
Hi Ivan, Next step in our road-map of improving mod_security is to add some protection to html forms. Attached to this mail I've set an initial proposal of our ideas of some ways of achieving html forms security. It would be great if you could check this ideas out and share your comments/ideas as you kindly did back when we discussed about cookie management. 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 cod= e, but for the very standard case this new feature is almost coded and teste= d. By the way, I would like to congratulate you for the work you've done on latest 2.0 version. It is really a huge rewrite that has brought so much clarity and readability to ms code, in addition to all new features and t= he ones to come due to brand new ms internal structure. Last but not least, we expect to be able to port/merge our contributions = to 2.x branch as soon as I'm back from my holidays and form protection is coded and tested. Best Regards. PD : Attached documents are text and html version of the proposal. I've started to use ReStructuredText to write our internal documentation. It allows you to write documentation in simple txt with minor and almost invisible markup (basically the usual space/tab/cr markup used in ordinary text), b= ut provides you a set of tools that let you "export"/transform this "source" text files to html/latex/pdf. I've found all that very useful because it all l= et you focus on important things not losing so much time in writing. It also allows you to store versioned documentation and access/modify it with the only help of a simple text-capable editor. If you're interested, check it out = at http://docutils.sourceforge.net/rst.html --=20 _________________________________ Carles Bonamusa P=E9rez Ingeniero de Software Dpto. Desarrollo de Soluciones cbo...@is... Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2=BA 1=AA 08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com ____________________________________ Este mensaje y los documentos que, en su caso lleve anexos, pueden contener informaci=F3n confidencial. Por ello, se informa a quien lo reciba por error que la informaci=F3n contenida en el mismo es reservada y su uso no autorizado est=E1 prohibido legalmente, por lo que en tal caso le rogamos que nos lo comunique por la misma v=EDa o por tel=E9fono (93 305 13 18), se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. En cumplimiento de la Ley Org=E1nica 15/1999 de 13 de diciembre de protecci=F3n de datos de car=E1cter personal, Internet Security Auditors S.L., le informa de que sus datos personales se han incluido en ficheros informatizados titularidad de Internet Security Auditors S.L., que ser=E1 el =FAnico destinatario de dichos datos, y cuya finalida= d exclusiva es la gesti=F3n de clientes y acciones de comunicaci=F3n comercial, y de que tiene la posibilidad de ejercer los derechos de acceso, rectificaci=F3n, cancelaci=F3n y oposici=F3n previstos en la ley mediante carta dirigida a Internet Security Auditors, c. Santander, 101. Edif. A. 2=BA 1=AA, 08030 Barcelona, o v=EDa e-mail a la siguiente direcci=F3n de correo: le...@is... |
From: Carles B. <cbo...@is...> - 2006-07-28 20:19:14
Attachments:
ms-rfc-2.html
ms-rfc-2.txt
|
Hi Ivan, Next step in our road-map of improving mod_security is to add some protection to html forms. Attached to this mail I've set an initial proposal of our ideas of some ways of achieving html forms security. It would be great if you could check this ideas out and share your comments/ideas as you kindly did back when we discussed about cookie management. We've been also working on a first approach to comment removal. As far=20 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 cod= e, but for the very standard case this new feature is almost coded and teste= d. By the way, I would like to congratulate you for the work you've done on latest 2.0 version. It is really a huge rewrite that has brought so much clarity and readability to ms code, in addition to all new features and t= he ones to come due to brand new ms internal structure. Last but not least, we expect to be able to port/merge our contributions = to 2.x branch as soon as I'm back from my holidays and form protection is coded and tested. Best Regards. PD : Attached documents are text and html version of the proposal. I've started to use ReStructuredText to write our internal documentation. It allows you to write documentation in simple txt with minor and almost invisible markup (basically the usual space/tab/cr markup used in ordinary text), b= ut provides you a set of tools that let you "export"/transform this "source" text files to html/latex/pdf. I've found all that very useful because it all l= et you focus on important things not losing so much time in writing. It also allows you to store versioned documentation and access/modify it with the only help of a simple text-capable editor. If you're interested, check it out = at http://docutils.sourceforge.net/rst.html --=20 _________________________________ Carles Bonamusa P=E9rez Ingeniero de Software Dpto. Desarrollo de Soluciones cbo...@is... Internet Security Auditors, S.L. c. Santander, 101. Edif. A. 2=BA 1=AA 08030 Barcelona Tel: 93 305 13 18 Fax: 93 278 22 48 www.isecauditors.com ____________________________________ Este mensaje y los documentos que, en su caso lleve anexos, pueden contener informaci=F3n confidencial. Por ello, se informa a quien lo reciba por error que la informaci=F3n contenida en el mismo es reservada y su uso no autorizado est=E1 prohibido legalmente, por lo que en tal caso le rogamos que nos lo comunique por la misma v=EDa o por tel=E9fono (93 305 13 18), se abstenga de realizar copias del mensaje o remitirlo o entregarlo a otra persona y proceda a borrarlo de inmediato. En cumplimiento de la Ley Org=E1nica 15/1999 de 13 de diciembre de protecci=F3n de datos de car=E1cter personal, Internet Security Auditors S.L., le informa de que sus datos personales se han incluido en ficheros informatizados titularidad de Internet Security Auditors S.L., que ser=E1 el =FAnico destinatario de dichos datos, y cuya finalida= d exclusiva es la gesti=F3n de clientes y acciones de comunicaci=F3n comercial, y de que tiene la posibilidad de ejercer los derechos de acceso, rectificaci=F3n, cancelaci=F3n y oposici=F3n previstos en la ley mediante carta dirigida a Internet Security Auditors, c. Santander, 101. Edif. A. 2=BA 1=AA, 08030 Barcelona, o v=EDa e-mail a la siguiente direcci=F3n de correo: le...@is... |
From: Ivan R. <iv...@we...> - 2006-07-27 19:17:35
|
Carles Bonamusa wrote: > Hi Ivan, > > Next step in our road-map of improving mod_security is to add some > protection > to html forms. Attached to this mail I've set an initial proposal of our > ideas > of some ways of achieving html forms security. It would be great if you > could > check this ideas out and share your comments/ideas as you kindly did back > when we discussed about cookie management. Thanks! I'll review it over the weekend and respond by Monday. > 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. Great! > By the way, I would like to congratulate you for the work you've done on > latest 2.0 version. It is really a huge rewrite that has brought so much > clarity and readability to ms code, in addition to all new features and the > ones to come due to brand new ms internal structure. Thanks. It's been a lot of hard work. But it's something I have planned for many months. Just FYI there's another bit missing, which I plan to implement to accommodate your contributions - a framework for ModSecurity modules. (There's not much work left to do.) > Last but not least, we expect to be able to port/merge our contributions to > 2.x branch as soon as I'm back from my holidays and form protection is > coded and > tested. Excellent. I will do my best to make that happen sooner rather than later. -- Ivan Ristic, Technical Director Thinking Stone, http://www.thinkingstone.com ModSecurity: Open source Web Application Firewall Apache Security (O'Reilly): http://www.apachesecurity.net |
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 |
From: Ivan R. <iv...@we...> - 2006-08-30 09:27:35
|
Carles Bonamusa wrote: > > Hi Ivan, > > I'm back from holidays with renewed energy and willing to get on coding > again. First of all I'd like to apologise for having been offline so > long, specially because our last conversation got kind of "suspended". No need to apologise! Not at all. Especially because I am on my holiday right now and will only be back in two weeks :) Ivan |