I'm currently in the process of developing a GWT 1.7.1 application that deals with a significant amount of persistent, user generated data so there is a risk of malicious XSS. One of the steps I am taking to prevent this is using org.apache.commons.lang.StringEscapeUtils.escapeHtml() server-side (Yes I am well aware that this will not prevent all possible XSS attacks as mentioned here and here).
This approach is causing a client-side problem since it appears that GWT is performing it's own client-side escaping (e.g. The server returns the string “Alice & Bob Inc.” and “Alice & Bob Inc.” is being rendered to the DOM which is incorrect). This is definitely happening client-side as the http response from the server contains the correctly encoded data. I have been going through the documentation for GWT and haven't found any reference to this feature. Is anyone aware of a way of disabling this behaviour?
How are you adding the value the server returns to the page? Could you be adding at as text? If you are sure the String is safe you can add it as HTML (there is usually an option for HTML) or specific Widgets like HTML.
btw Usually best not to return HTML encoded values from the server as you don't know how you may want to use them. I use the rule that you keep the values in their clean format till the last minute (adding to the document etc).
Related
I have an issue where forms are validated and if do not pass validation (validation is done in the back-end) are re displayed with original submitted data for the user to change. Originally this was not huge as I could just pass param data back into the template and have it re-displayed to the user. However, I came across issues with getting drop-downs and check boxes to retain the submitters original choices.
I checked out some of the Dancer friendly modules that did form validation and they seem nice, however, I have one more constraint: The forms and data selected needs to be able to be rebuilt and displayed again at a later time. So that means the data will need to be retrieved and the form built again displaying the same information previously selected, dropdowns already preselected, checkboxes checked, and data with the inputs.
I do not mind generating the forms and their selections dynamically from the backend using CGI form generating methods, but how can I get that data to play nice with dancer and display inside of a template?
If you're going to redisplay at a later time, it seems to me that you could go with a poor man's solution--save the rendered form with stuff selected to disk or database, and when it needs to be displayed again, just thow that cached stuff at them--or write the params to storage, and when you need to redisplay, go through the same code that generates the form now but use the saved params.
The "poor man's method" would be easy to implement but would bite you later when you find you are showing people stale versions of the form or whatever. (This is also a possible issue with the other version--the set of parameters might change over time, so there's risk there, too, but I would think less risk as you are caching less.)
I'm sorry that this is a "how to solve your problem" answer rather than a "here's a module that solves your problem answer". However, it's not too hard to store a set of params as a json blob or some other sort of frozen object, and there are modules for all the pieces of this.
I had an idea about website vulnerabilities, and I would like to know if it is possible. Also some suggestions on how to fix them.
If some part of my website writes data to the DOM and then calls the data back from it, would it be possible for someone to “hack” the server by editing the DOM in the browser?
For example, suppose I have some radio buttons. Each button has its own logic associated with it. If I remove one of the buttons, but fail to remove or comment out the logic, could someone go in and edit the DOM name of one of the buttons to the removed one, and upon submission have the server execute the logic associated with the removed radio button?
I understand how to fix that situation, by removing or commenting out the removed button’s logic, but I fear my site relies too heavily on such things that could be manipulated via the DOM. Hence, I’m wondering:
Is such a thing possible?
Is some complex validation method the only way to prevent “hacks” of this nature?
The answer to your question is yes. For example in many browsers you can open a javascript console and change not only the DOM but also the javascript on the site.
There is no guarantee that the code you write for a webpage will be run as you code it. Any user can change their copy. What they should not be able to do is change other people's copy. When they do this is called a cross site scripting (XSS) attack. (Typically done by adding script to a field which is saved in a database server and then served to another user.)
To protect your site you need to ensure that all web service calls are secure -- that is a user can't call them with malicious data and cause problems.
You also need to block against SQL injection attacks.
There is NO way to protect against a user changing the web page on their machine and having it do something you did not intend, so all validation needs to occur both in the browser and on the server.
As an example of how easy it is to change the local browser behavior, consider the browser extension. A browser extension is a pre-coded way to change the way web pages act locally.
(Think about ad-blockers as a specific example.)
Certain forms are too complicated to have them fit on one page. If, for example, a form involves large amounts of structured data, such as picking locations on a map, scheduling events in a calendar widget, or having certain parts of a form change depending on earlier input, it is of value to be able to break up a certain form over multiple pages.
This is easy to do with dynamic web pages and Javascript, as one would simply create a tab widget with different pages, and the actual submitted form would contain the whole tab widget and all of its input fields, yielding a single POST request for the entire operation.
Sometimes, however, it takes a long time to generate certain input fields; they might even be computationally intensive even after the page has been generated, taxing the low-end computer user's browser. Additionally, it becomes difficult or impossible to create forms that adapt themselves based on earlier input.
It therefore becomes necessary to split up a certain form over multiple full page requests.
This can prove to be difficult, especially since the first page of a form will POST to /location/a, which will issue a redirect to /location/b and requested as GET by the client. Passing the stored form data from POST /location/a to GET /location/b is where the difficulty lies.
Erwin Vervaet, the creator of Spring Web Flow (A subproject of the Spring framework, mostly known for its dependency injection capabilities) once wrote a blog article demonstrating this functionality in said framework, and also comparing it to the Lift Web Framework which implemented similar functionality. He then presents a challenge to other web frameworks, which is further described in a later article.
How would Yesod face this problem, especially considering its stateless REST-based nature?
Firstly, there's no pre-built solution to this in existence yet (that I'm aware of at least). And I'm not familiar with how the other frameworks mentioned solve the problem. So what I say here is pretty much conjecture. I'm fairly certain it would work, however.
The crux of the issue here is encoding page A's POST parameters into the GET request for page B. The simplest way to do that would be to stick page A's POST parameters into a session variable. However, doing so would break navigation pretty thoroughly: back/forward wouldn't work at all as described.
So we come back to REST: we need to encode the POST parameters into the request itself. That really means putting the information in either the requested path, or the query string. And the query string probably makes the most sense.
I'd be concerned about putting the raw POST parameters into the query string, as that would allow any proxy server to easily snoop the contents. So I'd like to leverage the existing cryptography from clientsession. In other words, we'll stick a signed, encrypted version of the previous form submission in a query string parameter.
To make it a bit more concrete:
User goes to page A via GET.
User submits page A via POST.
Server validates form submission, gets a value, serializes it, encrypts/hashes it.
User is redirected to page B as a GET, with a query string parameter containing the encrypted/hashed value from page A.
Continue this process as many times as desired.
On the final page, you can decrypt the query string parameter and have all of the form submissions.
This looks like it would be a fun add-on package to write if anyone's interested.
I am trying to find a way to test and verify my form validation is doing all it can to protect me from script injections. Is there a tool that I can use to test and verify my forms for any known vulnerabilities.
Are you talking about Webdevelopment?
You should prevalidate your forms using javascript or jquery logic. But this will not bring you any security, it will just reduce server traffic, because non valid forms will not be send to the server doing so.
Further more you have to validate your forms at the server using php or what ever you use on server side.
Do not forget to use htmlspecialchars whenever you display variable input values to be aware of xss attacks.
Use mysqlrealescapestring or some escaping for the dbs you are using. If you use an orm escaping is mostly done automaticly.
you asked for a tool? you can use the zend framework, it is complicated but it has some form validation automatisms.
E.g: you can validate ISBN numbers, email addresses or bar codes with it automatically.
I noticed this question was never answered well enough for me to except an answer. I ended up using a form fuzzer. A browser add on like this https://addons.mozilla.org/en-US/firefox/addon/immuniweb-self-fuzzer/ will enter data into the form inputs and try to break your form validation inputing various kinds of data. Best to work on a development/sandbox type environment since the data input an potentially destroy your database.
I am in the process of building a website content management system for one of my clients. It's a highly customized system, so I cannot use any "of the shelve" solution.
I need to allow my client to add pages to the website on the fly. I have two options here:
(1) Create a database driven page in the format of www.mycompany.com/page.aspx?catID=5&pageID=3 (query the database with the category and page ID's, grab the data and show it on the page) - or -
(2) Allow the management system to create static pages, something like www.mycompany.com/company/aboutus.aspx and www.mycompany.com/company/company_history.aspx , etc.
I believe that, while the former is much easier to implement, the latter is a better both for the user AND for Google.
My questions are (finally): (1) Would you agree that the latter is a better solution, and (2) What is the best way to implement such a solution? Should I create and update each file using the FileSystem (i.e. - the site's management system requires the user to supply a page/file name, page title and content, and creates the page on the fly based on these parameters)? Is there a better way?
Thank you!
It's entirely possible to have database driven pages with nice URLs. StackOverflow itself is a great example - this question's URL is http://stackoverflow.com/questions/1119274/adding-pages-on-the-fly-with-a-cms-system, but the page is built from the database, not static HTML.
I would use the first solution, but mask the addresses using a custom request handler. Basically, give each of your pages a unique string ID (such as about-us) and then, with your request handler that takes all requests, find this particular page in the database and render it.
See this article for some additional info (found it when googling for custom http handlers in ASP.NET.) In that article, it has the following handler added:
<add verb="*" path="*.piechart" type="PieChartHandler"/>
You would probably want to catch all paths (*), excluding certain media paths used for CSS, images and JavaScript.
More resources:
Custom HTTP Handler
HttpHandler in ASP.Net
I'd stay clear of static pages if I where you. Dynamic Data, MVC and some good planning should take you a long way!
What you need to do is to create some or many templates that each view/controller in mvc can use. Let whoever is responsible for the content handle it through dynamic data entities.
I would use the first idea, but work out a better URL scheme. If the system doesn't provide nice URLs (without ?), you'll have trouble getting the search engines to parse the whole site. Also using numbers instead of words make it hard on users to pass around URLs.
If you start to have performance problems you could add caching that would generate static pages from time to time. I would avoid doing that until you have to; caching can cause many headaches along the way to getting it right.
Although the existing advice is more-or-less sound, the commentators have failed to consider one factor which, admittedly, you haven't given much detail on. Are these pages that they'll edit once they're built, or a they one-shot creations? If the latter, your plan of generating static pages isn't quite so bad as they suggest. Why bother even having to think about database schemas and caching, when you can just serve flat content.
It will probably make for pretty lifeless, end-of-the-road pages, but if that's what you want ...