I maintain an asp.net 4.0 application, not MVC, based on some close source and I must implement some anti-xss in query parameters it uses. I can't access all the code and altering all the components is out of question. I can't upgrade the .net version, also.
Does it make sense to try to rewrite the path to encode/escape the query strings in order to encode the query strings, to avoid some xss injection using them?
Could it be done as the browsers do? Could it be done to encode when needed only, avoiding an infinite loop?
Related
I am starting to write my first web app with Node.js and Express. I have two approaches in mind.
Create two sets of routes. One that sends JSON, one that renders the page using a templating engine
Create a static website that makes API calls to the backend using AJAX, and have only routes for the API.
I understand that approach #2 depends on AJAX support in the browser, but if this was your project, based on the advantages and disadvantages of each approach, which would you choose and why?
If I am reading it right, both options #1 and #2 first set of routes is an API that returns JSON rather than sends it.
Assuming that in #2 you wouldn't create static pages with JavaScript doing AJAX calls, but rather still use express static routing like app.use('/', express.static(path.join(__dirname, 'dist'))); the difference between 2 approaches isn't that big.
Unless you already know some supported template language, such as mustache the cons are that you have to learn one and before that pick one (which isn't always an easy task from my experience!).
If you don't know one, depending on your application, you might still benefit from learning and using one. As an example you can think of a very generic UI where a single template could be reused very many times - like a generic database UI similar to, say well known phpmyadmin.
In case of static routing, you can achieve similar results by using a JavaScript framework which has components or templates, such as angular. If you aren't planning to use one, that could result in a lot of code duplication of otherwise re-usable widgets. And even when using one I can imagine a case when template engine would result in less code (or less files in your project at the very least). Not sure though if it's going to be easier to navigate and moreover to cover with tests when the project grows.
Without knowing more about your project it is hard to give more advice.
If the product you're developing is primarily static content with some dynamic pieces here and there, I'd recommend serving HTML from your backend via a templating system. A good example of this would be a blog. You'll end up with better SEO and there are less moving pieces to grok in this approach.
However, if you want to develop a single page application, I recommend using your backend entirely as an api, and writing your client side logic entirely in React/Vue/Angular/whatever. Single page applications have their front ends written entirely in javascript, and are best suited to highly dynamic, "app like" experiences online. Think gmail or facebook.
In my current project we use both approaches. Many views are static and data is obtained from API calls (we just use angular) or bootstrapped values (we load some objects with template, like user roles etc.)
However, some views are rendered on server site, because it easily allow us to dynamically inject values, tokens or other supporting data without making extra requests.
So, I vote for flexibility
I'm trying to secure my Spring MVC web app against cross-site scripting (XSS) attacks.
At first I thought I could simply set defaultHtmlEscape in my web.xml and be done. But I found that had no effect. As explained here -- Spring or App-Server escape html isn't working JAVA MVC, defaultHtmlEscape has no effect on INPUTS. It only sanitizes OUTPUTS within c:out tags.
So then I figured I'd write a filter to intercept requests, examine the parameters, and sanitize them as needed. But while looking into how to write the filter, I came across this -- XSS Filter to enctype="multipart/form-data" forms. It includes comments suggesting that filtering inputs is a bad idea, and that I should stick to filtering outputs.
Several posts mention HDIV and other third-party security solutions, but I'd rather not introduce a new third-party dependency to my project for something as basic as sanitization.
But filtering outputs seems inconvenient and error-prone. Are all the developers who touch my web app expected to remember to use c:out for EVERY output value on EVERY JSP page? Surely a global setting would be better? What's the best practice here?
Thanks in advance for your advice.
This is a big question. There is no easy or automatic way to do it. Every developer on your team should understand the basic aspects of this. The best practices are going to include input validation and output escaping.
Additionally, if you handle input that is expected to be html markup, you will have additional complications. AntiSAMY is a good place to go for that.
This article is a good place to start:
https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet
No there is no way in Spring MVC to sanitize user inputs.
However you can prevent XSS by setting defaultHtmlEscape to true in web.xml
Adding this will not sanitize data it will encode it, preventing XSS.
Refer to the link below for syntax
How do I prevent people from doing XSS in Spring MVC?
I'm looking to implement the Google crawlable AJAX states as described here:
http://code.google.com/web/ajaxcrawling/docs/getting-started.html
Essentially this requires specifying your AJAX states with a #!state value at the end of the url.
This should then be passed to the application server (PHP in my case) as part of the query string eg.
http://www.example.com/#!open would become http://www.example.com/?_escaped_fragment_=open
Unfortunately i'm having trouble figuring out how to implement this via mod_rewrite on Apache 2. Can anyone offer some help?
Cheers
James
The RFC 2396 section 4 says:
When a URI reference is used to perform a retrieval action on the
identified resource, the optional fragment identifier, separated from
the URI by a crosshatch ("#") character, consists of additional
reference information to be interpreted by the user agent after the
retrieval action has been successfully completed. As such, it is not
part of a URI, but is often used in conjunction with a URI.
That is, the fragment won't be visible for the web server so you'll have to look for some other method as mod_rewrite is a no go.
Depending on what language you are familiar with, you can install HTMLUnit if you're a Java dev or you could try to write a proxy and use it to fetch the parsed content by, i.e. Jaxer or a Firefox instance. I used Jaxer and is pretty easy to implement the crawlable ajax pages after you get used with the Jaxer API (which isn't complicated at all)
I am trying to find the optimal architecture for an ajax-heavy Django application I'm currently building. I'd like to keep a consistent way of doing forms, validation, fetching data, JSON message format but find it exceedingly hard to find a solution that can be used consistently.
Can someone point me in the right direction or share their view on best practice?
I make everything as normal views which display normally in the browser. That includes all the replies to AJAX requests (sub pages).
When I want to make bits of the site more dynamic I then use jQuery to do the AJAX, or in this case AJAH and just load the contents of one of the divs in the sub page into the requesting page.
This technique works really well - it is very easy to debug the sub pages as they are just normal pages, and jQuery makes your life very easy using these as part of an AJA[XH]ed page.
For all the answers to this, I can't believe no one's mentioned django-piston yet. It's mainly promoted for use in building REST APIs, but it can output JSON (which jQuery, among others, can consume) and works just like views in that you can do anything with a request, making it a great option for implementing AJAX interactions (or AJAJ [JSON], AJAH, etc whatever). It also supports form validation.
I can't think of any standard way to insert ajax into a Django application, but you can have a look to this tutorial.
You will also find more details on django's page about Ajax
Two weeks ago I made a write up how I implement sub-templates to use them in "normal" and "ajax" request (for Django it is the same). Maybe it is helpful for you.
+1 to Nick for pages displaying normally in the browser. That seems to be the best starting point.
The problem with the simplest AJAX approaches, such as Nick and vikingosegundo propose, is that you'll have to rely on the innerHTML property in your Javascript. This is the only way to dump the new HTML sent in the JSON. Some would consider this a Bad Thing.
Unfortunately I'm not aware of a standard way to replicate the display of forms using Javascript that matches the Django rendering. My approach (that I'm still working on) is to subclass the Django Form class so it outputs bits of Javascript along with the HTML from as_p() etc. These then replicate the form my manipulating the DOM.
From experience I know that managing an application where you generate the HTML on the server side and just "insert" it into your pages, becomes a nightmare. It is also impossible to test using the Django test framework. If you're using Selenium or a similar tool, it's ok, but you need to wait for the ajax request to go return so you need tons of sleeps in your test script, which may slow down your test suite.
If the purpose of using the Ajax technique is to create a good user interface, I would recommend going all in, like the GMail interface, and doing everything in the browser with JavaScript. I have written several apps like this using nothing but jQuery, state machines for managing UI state and JSON with ReST on the backend. Django, IMHO, is a perfect match for the backend in this case. There are even third party software for generating a ReST-interface to your models, which I've never used myself, but as far as I know they are great at the simple things, but you of course still need to do your own business logic.
With this approach, you do run into the problem of duplicating code in the JS and in your backend, such as form handling, validation, etc. I have been thinking about solving this with generating structured information about the forms and validation logic which I can use in JS. This could be compiled at deploy-time and be loaded as any other JS file.
Also, avoid XML. The browsers are slow at parsing it, it is a pain to generate and a pain to work with in the browser. Use JSON.
Im currently testing:
jQuery & backbone.js client-side
django-piston (intermediate layer)
Will write later my findings on my blog http://blog.sserrano.com
When it comes to URL Rewriting there are some alternatives these days like the IIS7 module or Urlrewriter.NET. However, as far as I can see those two are based on wildcards which I sadly cannot use.
My problem is that the data I'm working with have no real structure. A made up example:
Something.aspx?page=4 might be /Weapons/Flails/
Something.aspx=page=5 might be /Clothes/Dresses/Blue/
i.e. there is no clear match between page id and what kind of page it is pointing to. I guess this requires some kind of lookup (slugs?) in a db.
How would I implement this in the easiest way? Does any of the existing alternatives offer a solution to this or do I have to build my own module?
Thank you.
IIS7 had a regular Expression option not just wild card it also has Rewrite maps. which i think is what you are looking for, it could be your look up table.
when you set up a rewrite rule, use the drop down to find the regEx option.
also when you create the rule, the option for the map is there.
You can also use the Managed Fusion URL Rewriter and Reverse Proxy. It support the Apache mod_rewrite sytnax of configuring rewriting. And you can use this method described on my blog to create a module that can do a database lookup of these old ID's and redirect them to the correct location.
http://www.coderjournal.com/2008/12/creating-extension-module-net-url-rewriter-reverse-proxy/
Please contact me through my blog if you would like help setting up this type of rewriting.