form = SQLFORM(db.table) prevents again CSRF but does not limit access. For that you need to decorate the page with @auth.requires_login() etc.
Once SQLFORM stores data in database it is in UTF8. If you extract data from database and you display it in a page in any way other than wrapping in XML(...) it is automatically escaped and therefore prevents XSS attacks. If you use XML(...) to display the data you are vulnerable to XML attacks. On Monday, 4 January 2016 19:40:10 UTC-6, Joe wrote: > > Thanks very much Anthony, I appreciate the detailed explanation. This is > what my understanding was as well, but I wasn't 100% sure. In my case, the > input was user contact info and some text submitted by the form and kept > in the db records and not written back to a web page. But this brings up an > other question, if the input is by the login form where the user name is > written back out to the page "Welcome User", there Web2py of course, > automatically escaping any text as well, right? > > > On Tuesday, January 5, 2016 at 12:30:29 AM UTC+8, Anthony wrote: >> >> By default, SQLFORM protects against cross-site request forgery attacks >> (via a hidden _formkey field, with a matching formkey value in the >> session). And the DAL protects against SQL injection when making database >> inserts. However, at form submission/database-insert time, nothing prevents >> users from entering text that can later be used in a cross-site scripting >> attack. The reason is, such text is not dangerous merely by being stored in >> the database, but only when written back out to a web page. Therefore, >> web2py protects against cross-site scripting by automatically escaping any >> text written via a template. You can only override this default escaping by >> wrapping the text in the XML() helper (and if you want to make the >> unescaped text relatively safe, you can pass sanitize=True to XML). >> >> So, in this case, there is nothing dangerous about that text having been >> submitted and saved. However, you have to be careful what you then do with >> any user-submitted data. Do not write it back out to a web page without >> escaping or at least sanitizing it. >> >> Anthony >> >> On Monday, January 4, 2016 at 7:29:51 AM UTC-5, Joe wrote: >>> >>> I the db record text I had this: >>> >>> *sometext*+*www.mydomain.com <http://www.mydomain.com>*@ >>> *sometext.com >>> <http://sometext.com>*http://*sometext*.com/?url=*www.mydomain.com >>> <http://www.mydomain.com>*&id=e318 >>> >>> ..and more similar type of code. The input was long and it looked like >>> a cross site scripting attack with the intent to use my domain to send our >>> mass email >>> * or something like that...*All of this was in the record's text area >>> for comment processed by the SQLFORM. >>> >>> My understanding is that the form allows the special characters to be >>> processed but they are harmless. At least I hope they are. I just ran a >>> test and placed a line of html >>> in the form text area. This may not be the best way to test this, this >>> was the line <h1 style="color:green;">Testing form</h1> >>> It was processed and made it to the db record but the text wasn't h1 >>> size and wasn't green. This should mean that it's fine. >>> >>> Please let me know your thoughts. >>> >>> On Monday, January 4, 2016 at 6:14:34 PM UTC+8, Niphlod wrote: >>>> >>>> it's the same code. >>>> A call to >>>> http://yoursite/yourapp/controller/function?url=something&id=somethingelse >>>> would not pass validation as SQLFORM is CSRF protected. >>>> If you are sure that that call got a record into the db, something is >>>> really wrong with your application as web2py doesn't allow it out of the >>>> box. >>>> >>>> On Monday, January 4, 2016 at 11:04:49 AM UTC+1, Joe wrote: >>>>> >>>>> Thanks very much Niphlod, >>>>> >>>>> So, the special characters in the user input showing up in the table >>>>> records text is basically harmless, right? That's what I though. >>>>> >>>>> Thanks for the correct code. I actually thought the code was: >>>>> >>>>> *form = SQLFORM(db.table).process() * >>>>> *if form.accepted:* >>>>> do something >>>>> elif form.errors: >>>>> #errors this is probably where that call ended >>>>> So, the above is not correct? >>>>> >>>>> BTW: You mean this is where the attempt/call should have ended? It >>>>> didn't end there. The form actually processed the input with the special >>>>> characters. I read the entire input with the html code in it in the >>>>> database table records. It shouldn't have processed it because of the >>>>> special characters? I am probably misunderstanding you. Please kindly let >>>>> me know. >>>>> >>>>> Thanks again. >>>>> >>>>> Cheers, >>>>> >>>>> Joe >>>>> >>>>> >>>>> >>>>> On Monday, January 4, 2016 at 5:38:41 PM UTC+8, Niphlod wrote: >>>>>> >>>>>> any SQLFORM is csrf protected so those kind of attempts resulted in >>>>>> nothing. >>>>>> >>>>>> the "correct code" is >>>>>> >>>>>> form = SQLFORM(db.table) >>>>>> if form.process().accepted: >>>>>> do something >>>>>> elif form.errors: >>>>>> error # this is probably where that call ended >>>>>> >>>>>> return dict(form=form) >>>>>> >>>>>> On Monday, January 4, 2016 at 7:26:56 AM UTC+1, Joe wrote: >>>>>>> >>>>>>> When I create a form do I need to do anything other than just have >>>>>>> this line in the controller: >>>>>>> form = SQLFORM(db.example).process() >>>>>>> and then {{=form}} in the view? >>>>>>> As far as security, this is enough just like that, right? >>>>>>> >>>>>>> The reason I am asking because I just looked through the records in >>>>>>> the database administration and a couple of the records indicated that >>>>>>> someone was trying to hack my site by inserting html. >>>>>>> So if I see something like that in the records, I shouldn't worry, >>>>>>> right? >>>>>>> >>>>>>> It was just standard things like: >>>>>>> >>>>>>> *sometext*+*www.mydomain.com <http://www.mydomain.com>*@ >>>>>>> *sometext.com >>>>>>> <http://sometext.com>*http://*sometext*.com/?url=*www.mydomain.com >>>>>>> <http://www.mydomain.com>*&id=e318 >>>>>>> >>>>>>> I am pretty sure, this attempt didn't work but I would appreciate >>>>>>> some feedback so I can learn more about this issue. >>>>>>> >>>>>>> Thanks very much. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
