i would like to encode the value attribute using the ESAPI library using the specific method: ESAPI.encoder().encodeForHTMLAttribute(). My question is should i be using this method in the JSF itself or in the MessageBean? If i were to encode this in the JSF is this the correct syntax?
<h3></f:verbatim><h:outputText id="frsubject" value="#{MessageBean.frSubject}" /><f:verbatim></h3>
<h3></f:verbatim><h:outputText id="frsubject" value=<%= ESAPI.encoder().encodeForHTMLAttribute("#{MessageBean.frSubject}") %> /><f:verbatim></h3>
Thansk #BalusC. Sorry for the late response i was also under the impression that with i would be safe from xss attacks(using JSF 1.2). However in the fortify report the explanation is as below:
The use of certain encoding constructs, such as the tag with the escapeXml="true" attribute (the default behavior), will
prevent some, but not all cross-site scripting attacks. Depending on the context in which the data appear, characters beyond the
basic <, >, &, and " that are HTML-encoded and those beyond <, >, &, ", and ' that are XML-encoded may take on metameaning.
Relying on such encoding constructs is equivalent to using a weak blacklist to prevent cross-site scripting and might
allow an attacker to inject malicious code that will be executed in the browser. Because accurately identifying the context in
which the data appear statically is not always possible, Fortify Static Code Analyzer reports cross-site scripting findings even
when encoding is applied and presents them as Cross-Site Scripting: Poor Validation issues.
Related
I'm using TinyMCE as my online editor but I'm concerned of XSS attacks etc..
I though of replacing all < and >, but that doesn't seem to be an option with this kind of editor and I'm not sure removing script tags is enough too (what about onclick, onmouseover and other events).
What should be my approach to avoid such attacks?
You have to choose, security or convenience. The WYSIWYG editor like TinyMCE is very convenient. It allows non-experts to use a web interface to update some content with or without html tags. Its the lazy way to allow someone non-technical to update html, and it comes with all kinds of hazards.
When you give users access to TinyMCE interface to your database it is absolutely equal to giving them a database client to update data directly in your database.
ALso, note that today there is a great deal of Cross-Site-Scripting that is not malicious, that is in fact facebook, linkedin, youtube, etc integration that requires script references to third party domains etc.
So if you harden the TinyMCE tool so that XSS can not be added it will be useless to a serious web developer in many scenarios.
But if you need to make an add/edit/update/delete editor XSS proof you need to validate and sanitize all inputs and your best choice is to roll your own.
In theory you can eliminate XSS like this, but in practice its difficult. There always seems to be something that you've overlooked.
The best way I've found is to use a regular expression to only permit use of certain tags that you specify ( <strong>, <em> etc) and remove all others. You also need to look for attempts to circumvent your protection by users encoding characters.
My website http://www.imayne.com seems to have this issue, verified by MacAfee. Can someone show me how to fix this? (Title)
It says this:
General Solution:
When accepting user input ensure that you are HTML encoding potentially malicious characters if you ever display the data back to the client.
Ensure that parameters and user input are sanitized by doing the following:
Remove < input and replace with "<";
Remove > input and replace with ">";
Remove ' input and replace with "&apos";
Remove " input and replace with """;
Remove ) input and replace with ")";
Remove ( input and replace with "(";
I cannot seem to show the actual code. This website is showing something else.
Im not a web dev but I can do a little. Im trying to be PCI compliant.
Let me both answer your question and give you some advice. Preventing XSS properly needs to be done by defining a white-list of acceptable values at the point of user input, not a black-black of disallowed values. This needs to happen first and foremost before you even begin thinking about encoding.
Once you get to encoding, use a library from your chosen framework, don't attempt character substitution yourself. There's more information about this here in OWASP Top 10 for .NET developers part 2: Cross-Site Scripting (XSS) (don't worry about it being .NET orientated, the concepts are consistent across all frameworks).
Now for some friendly advice: get some expert support ASAP. You've got a fundamentally obvious reflective XSS flaw in an e-commerce site and based on your comments on this page, this is not something you want to tackle on your own. The obvious nature of this flaw suggests you've quite likely got more obscure problems in the site as well. By your own admission, "you're a noob here" and you're not going to gain the competence required to sufficiently secure a website such as this overnight.
The type of changes you are describing are often accomplished in several languages via an HTML Encoding function. What is the site written in. If this is an ASP.NET site this article may help:
http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx
In PHP use this function to wrap all text being output:
http://ch2.php.net/manual/en/function.htmlentities.php
Anyplace you see echo(...) or print(...) you can replace it with:
echo(htmlentities( $whateverWasHereOriginally, ENT_COMPAT));
Take a look at the examples section in the middle of the page for other guidance.
Follow those steps exactly, and you're good to go. The main thing is to ensure that you don't treat anything the user submits to you as code (HTML, SQL, Javascript, or otherwise). If you fail to properly clean up the inputs, you run the risk of script injection.
If you want to see a trivial example of this problem in action, search for
<span style="color:red">red</span>
on your site, and you'll see that the echoed search term is red.
Even though the HTML/CSS page is 100% valid according to http://validator.w3.org/
the page may still be broken in some browsers (*cough* IE7 *cough*).
Is there a unittest / validation tool that parses the html, css and javascript and searches the DOM for known browser bugs. Like using "position: relative" in combination with jQuery.slideUp()
That's hard with static analysis. You could have position: relative in a class you applied via an event handler to several elements, one of which you later selected by id and called slideUp() on. The validation tool you want would need the facilities of a browser and need to trigger all kinds of events to find those dangerous patterns.
Because Microsoft browsers are so excellent and are likely to give you a handful of new problems no one else has ever encountered before, it's hard to avoid spending time testing by hand; and on your way to finding crashes they crafted just for you, you'll catch the more mundane ones.
I'm looking to expose a number of services to the web. There will be static web pages with jQuery based JavaScript code that accesses these services, and there will also be all kinds of applications that may access these services. (Or nobody will care; that's also quite possible :-)
Each service would be well defined as a collection of methods that act on some number of input parameters, and return some number of output parameters. Most of it is REST, except for the concept of "identity" -- these services requires some log-in, and logging in does set you up with permissions on which methods on which services you're allowed to use, and what particular entities you're allowed to address using those methods.
Ideally, I want to expose the services using JSONP to make the services easy to consume in a cross-site way -- those static web applications shouldn't all have to be be served from the domain of my application servers.
The set of data types is fairly basic -- varchar (255 chars), text (8191 chars), id (32 chars, C-style identifier constraint), double, long (hard to do in JavaScript), bool, datetime, email (varchar matching a reges) and url (varchar matching a regex) would probably suffice for a very long time.
I want, if possible, to implement these services using an application service technology that can scale on multi-threaded cores -- 24 threads is standard on plain mid-range servers these days. Sticking with Python or Node.js would make me uneasy, because of their lack of threading support. Also, I would like for typing to be static, because I believe static typing prevents a certain class of bugs, which also talks against Python, Node.js, PHP and Ruby.
I also want to serve on Linux. That's a pretty hard requirement :-)
In the static language world, there are really only a few server frameworks or framework approaches. There's HttpListener with Mono. There's Jetty with Java. There's a few others. There are also a few much deeper frameworks, that have more overhead than I'd like -- J2EE, ASP.NET, etc. (In the dynamic world, you have Cake.PHP, Rails, Django, etc etc)
So, in the best of worlds, I'd like the GET URL /foo/bar?arg1=2&arg2=xyzzy to map to an object that I write of type foo, method bar, taking arguments arg1 and arg2 of type int and string (say). I want the server glue that sits between the HTTP GET and the object method to do two things:
1) Permission control (each method could have one or more required permissions)
2) Type checking (each argument should be verified against expected and coerced from the URL string format to the native typ)
Once the method returns one or more values (key/value pairs), the glue should make sure that the return values are also according to spec, convert to proper JSON, and should take care of returning an appropriate error result if an exception was thrown within the code.
I've been looking high and low for this kind of solution, but all solutions I find are pretty far off. JSP and ASP all start out with a HTML assumption -- I'm generally generating JSON, which doesn't integrate as well with the syntax (to put it mildly). JSPX, as well as a number of other technologies (HttpListener, CGI, Python Twisted, ...) all stop at the "do_GET" level -- no dispatch into objects, no permission control, no type checking. All the higher-level frameworks, however, add a lot more on top of that, and often adds complex routing that's not something I need -- and as often as not, still don't do permission checking, but instead leaves that as something you have to write manually in each function implementation.
I think the closest I could find to what I want is Thrift. However, it still doesn't do permission checking, and the "PHP server" support it has seems to be a dumb PHP cli process listening on port 80 instead of integrating with Apache, and it's not set up to support JSONP.
Have I missed something? Is there some (preferrably statically typed and multi-thread-supporting) server technology that will do type checking and permission checking and simple object-method dispatch, without tons of other cruft to get in the way, and can be called from (and respond to) JSONP?
Should I extend Thrift? Adding permission constraints on each method would be a fairly substantial extension, but at least I'd get the other support that Thrift has. (And then I'd have to add JSONP support, and ...)
Is there some (preferrably statically typed and multi-thread-supporting) server technology that will do type checking and permission checking and simple object-method dispatch, without tons of other cruft to get in the way
Scala (static, actors for threading/concurrency & dispatch, no cruft) + Thrift.
I believe the latest thrift has javascript support (not sure about JSONP).
As for authentication, see my answer to this question.
There really doesn't exist any good framework at the right level for this. Existing frameworks are either too low level (think boost::asio), or too high level (think cake, rails, etc). The closest option is probably Erlang/WebMachine. I guess the reason for this is that most web apps end up having a common set of higher-level requirements that then end up migrating into whatever the web framework is, thus lifting it out of the level where I'm looking to go.
We are looking at using a library to help us detect SQL injections.
We are using sprocs and parametrized statements, but for the sake of this post that we are only using some sore of library that detects/ verifies user input.
Whats the best one? Easiest to implement? Easiest to update/manage?
Why prefer one over the other?
On a side note:
I've just started using Owasp. with C#.
I was hoping that there would be more default rules while validating.
When using the isValid function, there are only 5 default rules.
CREDIT_CARD -- Rule name key for the credit card validation rule.
DATE -- Rule name key for the date validation rule.
DOUBLE -- Rule name key for the double validation rule.
INTEGER -- Rule name key for the integer validation rule.
PRINTABLE -- Rule name key for the printable validation rule.
I was hoping that there would be more default rules for string SQL Injection Detection.
Thanks
Using stored procs is a pretty big step in the right direction. What I’d add to that is input validation which it looks like you’re trying to do with the OWASP ESAPI library but it pretty simple to implement by regex in most cases. You should find plenty of publicly available patterns for most untrusted data.
The other thing you might want to do is to apply the principle of least privilege at your data layer. Consider using more than one SQL account and restricting the access of your account(s) used by publicly facing users to the absolute bare minimum functions. You’re using stored procs; try and avoid any datareader or datareader rights if you haven’t already.
More info in OWASP Top 10 for .NET developers part 1: Injection
I'm using AntiXSS for validating user input - specifically including protection aganist SQL Injection. I've seen a few attacks but nothings gotten through - so seems to work well for me.
Also - Troy knows what he's talking about - His article on the subject is a really good one :)