iSeller Commerce
iSeller POS Retail
iSeller POS F&B
iSeller POS Express
Crosslight
WebUI
ClientUI
What's New
Download Trial
Web Solution
Mobile Solution
Enterprise Solution
Custom Development
Blog
Community
Latest Development Blogs
ForumPostTopic
Browse By Tag
Hi,
We use the latest version of WebGrid 6.
In our server infrastructure there are some servers in front of our IIS. These servers do input validation to prevent cross site scripting attacks. I have no control on what is filtered there, but I received a blocking log.
The problem is that anything that looks like XML will be blocked. A string like:
" abc = … >
anywhere in a POST data field will be blocked. And I found a blocked (AJAX?) POST request, looking like it came from WebGrid.
Interestingly our application works - including all WebGrid functionality. But we do see some problems.
Questions:
It would be great if you could answer these four questions.
Regards,
Eric
Hello Eric,
Our controls use xml for client-server data exchange. So it's already by default and not a bug. For your information, WebGrid supports standard high security evironments in general. Some of users ever tested in SSH, https and others. Our Ajax postback does not specify in HTTP header field. But you can use a input field (http form) to ditinguish it. Hope this information helps.
Regards,Handy
Hi Eric,
Sorry for the late response, I just got news from the development team, they said that both the data storage (the initial control state that sent from server) and the data that the client sent to the server will be using JSON. The response will be likely become JSON too, although it may still consist HTML for the server rendering. Basically we want to eliminate XML in this new enhancement.
The 2011 R1 will be ready in late Q1/early Q2 this year.
Best Regards,
Gordon Tumewu
Deeply apologized for the late response. Our developer teams has decided to postpone the enhancement due to the tight schedule. This enhancement would affect all our ASP.Net product because it needs to be implemented in Framework level which needs extensive testing to ensure the delivery quality.The enhancement would be implemented after R1 release, the end of April.
Hi Handy,
In the meantime I could get a HTTP protocol analyzer installed. After loading the page for the first time, I can see a few requests like this:
POST /blabla.aspx HTTP/1.1Accept: */*[more header fields]WebGridRequest=¢WebGrid>¢request id="ctl00_ContentPlaceHolder1_grdMain" action="Custom"/>¢/WebGrid>&__VIEWSTATE=/wEP...
(The character ¢ stands for ASCII code 03.)
As you can see, there is request data from WebGrid. And this data contains the 'greater as' sign, but not used as correct XML. Such data looks exactly like input from a hacker trying to XSS-exploit a normal web form.
This means that requests like these get filtered away by security software that do input validation.
This means in other words that WebGrid is not compatible with such environments. Can you confirm that this is by design?
We could not say that is bug. As design, we have our default mechanism to encode the xml before sending it to server. The incompability might be true only for some scenario, which does not allow such characters. But commonly, 99.9% others get it work so far. We would like to see the details of your scenario first before can decide what is the issue.
Or, you can use ClientBinding. ClientBinding would not post anything to server which should be greate advantage in your scenario. If you need an Ajax process, you can try to integrate it with our control 'WebFlyPostBackManager'.
Maybe you didn't understand the problem we are facing.
Your control is sending this data to the webserver:
WebGridRequest= ¢WebGrid>¢request id="ctl00_ContentPlaceHolder1_grdMain" action="Custom"/>¢/WebGrid>
(¢=0x03 character)
And between the client and the server there is a security filter that checks for this pattern in any field:
As you can see this does match. This means that the entire POST request will be filtered away and not even reach the IIS.
This filtering is not done for fun. This is because typical XSS-exploiting attacks are using exactly this pattern.
The product that filters this away is AdNovum NevisProxy Version 3.9. Please see here:
http://www.adnovum.com/en/products/index.php?page=secprod&subpage=nevis&subsubpage=nevisproxy
In other words, your WebGrid is not compatible with using such security software. I imagine that any other security software with input validation would also filter these requests away, so it's not specifically this product.
In any case I would suggest that you make your WebGrid compatible with such filtering software.
Client Binding is not possible and even if using the WebFlyPostBackManager would work, this would mean to reengineer the entire application. We use WebGrid on every page and I don't want to change all this handling. For me this just means we cannot deploy the existing application with WebGrids to such an environment.
After discussed with our developer, they consider to make an enhancement to avoid the /03(¢) chararcter. A work item has been created regarding this request.
Thanks for your feedback. I think removing the /03 character would be a good idea, as such characters cannot be entered by a user in normal form fields. But it won't solve the problem. The problem is more the use of the greater-than characters ('>') out of the context of proper XML and also this together with constructs like =" etc. in the same form field. This looks like a typical XSS injection attack.
I would suggest that you work together with someone that understands the risks of XSS attacks to resolve this problem. Or, if you (I mean your company) want to do all yourself, then you should start getting knowledge on this topic.
Here some great links to start with:
Thanks for the valuable feedback. I will forward this to the development team, hopefully they can solve the issue immediately.
Thanks Gordon,
Please let me know as soon as you have any feedback from the developers.
I need to know as soon as possible if this will be changed or not as this decides how we will use your product in the future. And we have to make some decisions in the next days.
Our development team will create a new feature in our framework so WebGrid can output JSON instead of XML for the call back data. The enhancement will be ready at 2011 R1 milestones.
Hi Gordon,
Thanks for your reply. From your answer I understand that that data being sent back from the server will be in JSON format instead of XML.
Please notice that the problem mentioned in this thread is not the server data. The problem is the data that the client (the web browser) sends to the server. That currently is neither XML nor any other standard format. It is some Intersoft proprietary format, as you can see in one of my posts above. I need to know if this will change. Or did you want to say that the data format sent by the client will also change to JSON format?
You also didn't mention when the 2011 R1 will be released. If this is not certain, can you give an estimation?
Thanks,
Ok, thanks. Would it be possible to test a beta version as soon as this JSON change is built in? I could test then if this change works as expected in that environment.
Hi Handy
Yes, I understand that you are working on WebGrid7. I'll await your update then.
Ok. Thank you for your understanding.
Is there a beta available in the meantime that already has this change built-in? It doesn't matter if there are other bugs, but we would like to test it as soon as possible if it solves these filter problems. You wanted to release 2011 R1 end of Q1, so I thought a beta should be ready in the meantime?
You have my email and our developer login, so if you could provide us this beta today, it would be great to test it.
We don't have a beta installer for 2011R1 release for now. I need to ask to our development teams if we are planning to release the beta or not before the release.
In an earlier post (see above) you promised me a beta as soon as this feature is built into your code. Or did I misunderstand you there? You don't have to make a public beta because of that.
I don't need an installer. Actually I could just place the DLLs into the bin folder of my project - that should be sufficient, right?
You would need to install the product in order to run WebGrid. For you information, 2011R1 still sticks on WebGrid7. You can download our current installer to have WebGrid7.However, I still haven't received any news if this feature has been enhanced.
I know that there will be some issues installing it. We didn't even buy v7 yet. But I'm sure we will find a way to test it.
But I think the most important issue is if this feature is already implemented or not. Instead of waiting for news, maybe you can ask them for the status?
We need to try asap if the new version resolves our problems or if we have to replace all our grids with another product. Therefore we need this beta as soon as possible. Please update me.
This is bad news. But at least now we know how to continue (replace WebGrid with something else). Thanks for your answer. But please still update this thread if you have implemented this change.
Ok, I will update the news. Our developer teams have addressed this enhancement soon after we relased R1.
Hi, Handy. In the other thread you mention that this is solved in SP1. Can you confirm here and update this thread as soon as it's fixed? Or is there a beta version available that I could test if this solves our problems?
Yes, Our developer agreed to fix this in SP1. There is no beta release. But you can try our 30days trial when install our SP1.
Yes, I know that you promised to fix it. But has it been fixed by now? And is SP1 with the fix released? If not, when, if yes where?
Unfortunately, due to other high priorities and urgent issues, we have to shipped SP1 earlier than expected. As the results, the SP1 doesn't include the particular work items associated to your issues. We will continue to address the rest of work items in the upcoming hotfix based on our work items queues and priorities. Thank you for your understanding in this matter. SP1 would be release in the short time.
Ok, so please update this thread when this bug is fixed or when you know when this gets fixed.
or
Choose this if you're already a member of Intersoft Community Forum. You can link your OpenID account to your existing Intersoft Social ID.
Choose this if you don't have an Intersoft account yet. Your authenticated OpenID will be automatically linked to your new Intersoft account.
Enter your Wordpress Blogname