jQuery UI Widgets › Forums › Grid › Cross Site Scripting (XSS)
Tagged: XSS Cross site scripting
This topic contains 8 replies, has 6 voices, and was last updated by admin 4 years, 6 months ago.
-
Author
-
Dear Sir,
Can jqxGrid prevent the cross site scripting attack?
I had tested by insert data “alert(“Hello”);” to the grid about 2 months ago, it display hello alert box. But I tested it again it display blank.Best Regards,
WijitHi Wijit,
No, jqxGrid cannot prevent attacks.
Best Regards,
Peter StoevjQWidgets Team
http://www.jqwidgets.comCan you please let us know if any update on preventing the cross site scripting attack? If it is not available in JQWidgets then can you please let us know any workaround?
jQWidgets
The least someone could do is give some pointers on how anyone should use your framework without leaving a gaping security hole in their app?
Now you could just *ignore* this question and kick the can down the road… But this is unwise:
1) Some users of your framework may well just choose to post this question on high profile websites like stack overflow… Which will bring awareness to what is an apparent shortcoming… Whilst useful answers may yield some work arounds, it is likely a few comments will suggest jQWidgets shouldn’t be a first choice of frameworks…
2) Security is never a top priority until it is too late…. But don’t take my word for it – go ask the high profile executives at Equifax who made the error of not addressing a security hole until it was too late…:
3) Security is really a top priority, more so now than ever before. The recent data breach at Equifax probably has Chief Technology Officers around the country reviewing security to make sure they don’t suffer a similar fate. Whilst there is nothing to suggest the attack was XSS, a security hole is a security hole.
4) The financial cost of pausing and considering this is a small price to pay compared to the potential financial damage inaction could inflict.
You could just reply that “it is the responsibility of customers to incorporate XSS mitigation as needed”, but that approach isn’t going to wash if a major user of your framework fails to do this and suffers harm from a XSS attack…
!?
We use Inputs the way they are in HTML as pure HTML Elements. We do not restrict user Inputs and do not write special logic to do that. If someone needs to restrict user inputs, this can be done with javascript modifications.
The issue is when untrusted data goes back into the grid – protection can at least be applied in the inbound data. There is no good reason to allow non-escaped executable javascript code like [script] alert(‘Evil code here’) [/script] to go back into the grid. That is like arguing “We don’t fit seatbelts to the cars we sell, just in case people find them a nuisance”. Putting regulations aside, the weight of necessity to fit them far exceed the minor inconvenience they may pose.
Ok, jquser. Thank you for writing in our Forum. I think people understood your point. If we implement logic built-in our Grid, information about it will be available here: https://www.jqwidgets.com/jquery-widgets-documentation/documentation/releasehistory/releasehistory.htm.
Hey jQWidgets team,
We experience the very same issue. Everywhere your grid components isused we are vulnerable to XSS attacks…!
Is there any update on this? Every major UI framework/lib (Vue, Angular, React) has built in XSS prevention data sanitizing.
If still no fix exists, please let me know how I can prevent this globally?
We use your lib in multiple project, hundreds of grid components are already there. I need some global fix. Changing each grid individually would is rather impossible…Hi kapalkat,
XSS prevention is built-in for several years in our jqxGrid. If you prefer using it with Angular, Vue or React you can also do that. Our component is available for these frameworks, too.
Best Regards,
Peter StoevjQWidgets Team
https://www.jqwidgets.com/ -
AuthorPosts
You must be logged in to reply to this topic.