We have a site where we're using zxcvbn by Dropbox to inform users of their password strength, however, we've been getting occasional reports that it doesn't work.
Turns out that these users (reasonably rare) are accessing our website from their workplace which has a strict corporate firewall policy, because the js file contains swearwords and NSFW words (to mark the password as insecure if it contains these commonly used words), the whole JS file is being blocked from loading.
The rest of our site loads fine, including other JS files.
How could we encrypt or minify this js file to a point where it didn't get blocked for having "bad" words in the request, but be successfully decrypted at the client side to actually do it's job and detect unsafe passwords?
This JS Fiddle will (sort of) demonstrate the problem: https://jsfiddle.net/0cgap96m/3/
<script src="https://cdnjs.cloudflare.com/ajax/libs/zxcvbn/4.4.2/zxcvbn.js" integrity="sha512-TZlMGFY9xKj38t/5m2FzJ+RM/aD5alMHDe26p0mYUMoCF5G7ibfHUQILq0qQPV3wlsnCwL+TPRNK4vIWGLOkUQ==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
<div id="test">
</div>
window.onload = function(){
var name = prompt("Put in a fake password to test?");
var passwordStrength = zxcvbn(name);
document.getElementById('test').innerHTML = JSON.stringify(passwordStrength);
};
That should work fine normally - now try blocking https://cdnjs.cloudflare.com/ajax/libs/zxcvbn/4.4.2/zxcvbn.js using an adblocker or something, and it'll obviously start failing. This is essentially what's happening for the users, but it's blocked by their corporate firewall rather than a local adblocker.
To confound the filter, you can try substituting the literal characters with JavaScript's syntax for the unicode representation of those characters.
This works even with identifiers!
var f\u006F\u006F = 'b\u0061\u0072';
console.log(foo); // outputs: bar
You could download the built js file and alter the passwords list, to split up the string in between the NSFW words. Then your copy of the library instead.
In zxcvbn.js the insecure words are defined like this (shortened here for this example)
var frequency_lists;frequency_lists=
{passwords:"123456,password,eatshit,goodluck,starcraft"}
So, by doing this:
var frequency_lists;frequency_lists=
{passwords:"123456,password,eatsh" + "it,goodluck,starcraft"}
a firewall scanning for swear words shouldn't recognize that as a swear anymore.
EDIT:
I might suggest a PR to their repo to have their code build with this format might be a better solution with the additional benefit of solving the issue for anyone else using this library, as well as allowing you to update to newer versions. But from quickly looking at the github, I see you'd need to be familiar with coffeescript + python. The original solution is much quicker and doesn't require knowledge in other languages.
how about a simple error handling client-side and a proper validation server-side?
Actually, you don't even need the validation, but if the typed/submitted password is sent to evaluation on server-side when client-side is not available may cover all the bases you need.
And if you need validation, well you should have it server-side, too, anyway, right?
Related
I am analyzing our software using Fortify static code analysis. Fortify reports that we have a cross site scripting vulnerability (reflected), when I don't think we actually do.
I can either try to argue the point with my customer to convince them that it's safe (something no one wants to do as it requires an audit) or make Fortify happy;
I get a form parameter from the request in ASP.NET, and 'manually' (not using an API) escape it (escape any newlines, \ chars, quotes and remove any script tags). I then dump it back to the browser as
output.Write("var enteredText = \"" + htmlEscape( Form.Params["enteredText"] ) +"\"");
Fortify complains unless I do
output.Write("var enteredText = \"" + htmlEscape( HttpUtility.HtmlEncode(Form.Params["enteredText"]) ) +"\"");
but this means that to use the Javascript var 'enteredText' I have to HTML decode it using Javascript, which means another 10k of code on my app (unless I'm wrong). The whole encoding and decoding of <> and entities in this circumstance is redundant, no?
How can I appease Fortify?
If the application allows arbitrary JavaScript in the enteredText field and has it executed in the browser as JavaScript you indeed have a reflected cross-site-scripting vulnerability, and it is very serious. Anybody that can cause a user to form post against your application (with, say, a spear phishing attack) can cause all sorts of mayhem against the user. This is a very straightforward attack.
So, the fix is one of the following
Reject JavaScript (and HTML and CSS) in this enteredText field. Or, if this breaks your application:
Review the use case that requires executable code in the enteredText field and whitelist acceptable values. For JavaScript reject anything that could cause rewriting of the page: event handlers for OnLoad(), document.body.innerHTML (for example), or redirecting the user's browser.
Also reject anything that could post to remote servers (form, img, css tags for example). As you imply this could be a lot of code.
This is just a quick example, you'll need to do the research on the type of tags and event handlers that can be used in a cross site scripting attack. If you don't reject those in the enteredText field you'll still have the vulnerability.
Hope this helps. Good luck.
Sorry I got a IE8/javascript stack and my anwser was truncated. What I tried to say is:
If by 'sanitizes the output' you mean the htmlEscape() function, escaping typically does not address cross-site scripting vulnerabilities. You can really only prevent cross-site scripting by whitelist validation and the Fortify finding is justified. Now, if htmlEscape does solve the issue (e.g. it does more than escaping the output) you can make sure that Fortify can find that code, or write a 'clense rule' in Fortify so that it ignores vunlerabilities that have this call.
Customers are increasingly having critical software scanned with Fortify and MetaSploit. I feel your pain.
I'd like to be able to determine if the beginning portion (ideally first MB or so) of a file is of a password protected rar file. I don't just need to know if it's a rar file, I need to ensure that the file is password protected.
Is this possible? I know that the rar format is a proprietary format, but is this possible?
Edit:
I'd like to do this by examining the file's content, with either javascript or perl. It should not have access to the rar library.
Edit2:
With at least some consistency so far, I have been able to determine that the 10th byte appears to be always set to zero if no encryption is enabled. I haven't done enough testing yet to confirm this works reliably yet, but nonetheless, that is the result I am seeing.
My experiments gave me the following subroutine:
sub is_rarfile_protected {
my ($rar_filename) = #_;
open my $rar_fh, '<', $rar_filename or die $!, "\n";
sysread $rar_fh, my $mark, 25;
return ord (substr $mark, -1) & 0b100;
}
... which works for me so far.
Sadly, I don't have Rar installed, so I cannot check whether it'll work on all the password-encrypted rar-files (including multi-volumes, etc.) or not.
You could always try this
For those who can't perlmonks:
Re: Determine if a file is password protected
by rubasov:
If you don't want to implement the file format specific test for each of your extensions, then you can peek in the randomness of your data. Any well designed encryption scheme will result random looking encrypted data (to resist statistical analysis). But if the encryption is poorly designed this won't be much help for you.
Beware that this approach has serious caveats: if your data can be real/pseudo random or compressed data, then it will also look like than a pile of random bits, so for example you won't be able to distinguish between a simple and an encrypted rar/zip file. (And don't forget that simple looking document formats can use compression internally.)
For the concrete implementation search for the chi square test on CPAN (I haven't looked but I'm almost sure you'll find some implementation) and try to experiment with it whether it can be good enough for your purpose.
I'm new to ColdFusion, so I'm not sure if there's an easy way to do this. I've been assigned to fix XSS vulnerabilities site-wide on this CF site. Unfortunately, there are tons of pages that are taking user input, and it would be near impossible to go in and modify them all.
Is there a way (in CF or JS) to easily prevent XSS attacks across the entire site?
I hate to break it out to you, but -
XSS is an Output problem, not an Input problem. Filtering/Validating input is an additional layer of defence, but it can never protect you completely from XSS. Take a look at XSS cheatsheet by RSnake - there's just too many ways to escape a filter.
There is no easy way to fix a legacy application. You have to properly encode anything that you put in your html or javascript files, and that does mean revisiting every piece of code that generates html.
See OWASP's XSS prevention cheat sheet for information on how to prevent XSS.
Some comments below suggest that input validation is a better strategy rather than encoding/escaping at the time of output. I'll just quote from OWASP's XSS prevention cheat sheet -
Traditionally, input validation has been the preferred approach for handling untrusted data. However, input validation is not a great solution for injection attacks. First, input validation is typically done when the data is received, before the destination is known. That means that we don't know which characters might be significant in the target interpreter. Second, and possibly even more importantly, applications must allow potentially harmful characters in. For example, should poor Mr. O'Malley be prevented from registering in the database simply because SQL considers ' a special character?
To elaborate - when the user enters a string like O'Malley, you don't know whether you need that string in javascript, or in html or in some other language. If its in javascript, you have to render it as O\x27Malley, and if its in HTML, it should look like O'Malley. Which is why it is recommended that in your database the string should be stored exactly the way the user entered, and then you escape it appropriately according to the final destination of the string.
One thing you should look at is implementing an application firewall like Portcullis: http://www.codfusion.com/blog/page.cfm/projects/portcullis which includes a much stronger system then the built in scriptProtect which is easily defeated.
These are a good starting point for preventing many attacks but for XSS you are going to end up going in by hand and verifying that you are using things like HTMLEditFormat() on any outputs that can be touched by the client side or client data to prevent outputting valid html/js code.
The ColdFusion 9 Livedocs describe a setting called "scriptProtect" which allows you to utilize coldfusion's protection. I've have not used it yet, so I'm not sure how effective it is.
However, if you implement a third-party or your own method of handling it, you would most likely want to put it in the "onRequestStart" event of the application to allow it to handle the entire site when it comes to URL and FORM scope violations (because every request would execute that code).
Besides applying all the ColdFusion hot fixes and patches you can also:
Not full proof but helps, Set the following under CFADMIN > Settings > "Enable Global Script Protection"
Add CSRFToken to your forms http://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
Check http Referer
Add validation for all User inputs
Use cfqueryparam for your queries
Add HTMLEditFormat() on any outputs
Besides Peter Freitag's excellent blog you should also subscribe to Jason Dean's http://www.12robots.com
I use DropBox and I've had some trouble reaching to my files from other computers:
I not always want to login to anything when I'm in a public computer, but I like being able to reach my stuff from wherever I am.
So I've made a simple application that when put in the public folder, ran and given the right UID, creates (still in your public folder) an HTML of all the content in the folder (including subfolders) as a tree of links.
But I didn't risk loading it anywhere, since there are slightly private things in there (yes, I know that the folder's name is "PUBLIC").
So I've came up with the idea to make it a simple login page, given the right password, the rest of the page should load. brilliant!, but how?
If I did this by redirecting to other HTML on the same folder, I'd still put the html link in the web history and the "url's accessed" history of the administrator. So I should generate itin the same page.
I've done it:
alt text http://dl.dropbox.com/u/3045472/validate.png
And currently the page is a textbox and a button, and only if you type in the right password (defined in the generator) the rest of the page (with the link-tree) loads. The fault is that everything (password, URL's) is easily reachable through the source code.
Now, assuming I only want to avoid silly people to get it all too easily, not make a bulletproof all-content-holding NSA certified website, I though about some ways to make these information a bit harder to get.
As you may have already figured, I use a streamwritter to write an html file (head, loop through links, bottom), then it's extremely configurable, and I can come up with a pretty messy-but-working c# code, though my javascript knowledge is not that good.
Public links in DropBox look like this:
Summarizing: How do I hide the URL's ande the password to show them (MAINLY the password, of course) in my source-code so that no that it should require some effort on reading ?
P.S.: It's not that personal, if someone REALLY wants it, it could never be 100% protected, and if it was that important, I wouldnt put it in the public folder, also, if the dude really wants to get it that hard, he should deserve it.
P.S. 2.: "Use the ultra-3000'tron obfuscator!!11" is not a real answer, since my javascript is GENERATED by my c# program.
P.S. 3.: I don't want other solutions as "use a serverside application and host it somewhere to redirect and bla bla" or "compress the links in a .RAR file and put a password in it" since I'm doing this ALSO to learn, and I want the thrill of it =)
Update 1:
The one answer so far gives a perfect way (according to this question) to hide my password.
Now I want a good way to hide the URL's, maby a code snippet of the example URL I gave being composed, and if it's too tricky, maby how to generate it in C#, or anything ?
Update 2:
I thought about maybe making three "obfuscating methods" and choosing them randomly in the runtime. So anyone who figures out how to read one XML, could only read about one third of them, and maybe having a hard time finding the other rest of this third..
Update 3:
Just thought about REGEX, the URL could be neatly crowded by dummy not-url-allowed characters added randomly that would be removed by something like:
regex.replace(url, ^[^\w\d/:-\.%]+$,"")
So the nosy dude should have to be pretty advanced into programming somehow, eh? could anyone tell me if it would work or not ?
Well, as it seems you already know, this is a rather poor choice of security mechanism, but if you insist...
Don't store the actual string in the source. Store, for example, its MD5 hash. Then, when the user types in a password, compute its MD5 hash and compare it with the expected one.
Check out:
MD5 in JavaScript
MD5 in C#
To elaborate on miorel's idea, you can also encrypt the whole page, using password as a key. Basically, encode all content into one big string, ask for the password and decrypt that string. If the password is wrong, it will show loads of rubbish, that is it. Like
content = "encrypted string"
function decrypt(str, key) { your algorithm of choice here }
document.write(decrypt(content, prompt('Password?')))
The only thing you need is a decrypt implementation in javascript - but that's easy to google out, for example here or here.
This also renders the separate 'login' page useless.
Granted, this is akin to asking how you can strip in public without people seeing you, but given that, I'm assuming that the password you are trying to store is the one to DropBox. I suppose you could obfuscate the password and store it in a cookie. That would at least prevent someone from simply viewing the source to see the password, but obviously wouldn't stop someone running something like Fiddler and seeing it.
[snipped server side suggestion]
EDIT: To munge the Urls, why don't you simply build the urls on the fly and have the links call a javascript function to get the url? Your server-side code would populate an array in this function with obfuscated urls and the calling code would simply pass an index into the array. Thus, on viewing the source, there would be no instances of "http" anywhere other than static unsecure links.
ADDITION Ok. now that I have a better bead on the problem, it is easier to devise solution. There are libraries for doing encryption on the net in javascript (e.g. http://point-at-infinity.org/jsaes/) but the problem comes down to key management. Since its javascript, it is going to be public but there are hoops you can devise to make it harder to determine the key. In general, those tricks involve indirection. For example, store a lengthy stream of random characters (e.g. 40-50 or more) that is generated by your C# code and stored in the HTM file. In addition, the C# code would would store into your javascript function an array numeric values that represent pointers into the long stream of text that were used by the C# code to encrypt the passwords (or just the whole url).
I have an asp-based website which I would like to add spell checking capabilities to the textarea elements on the page. Most of the pages are generated from an engine, though I can add JavaScript to them. So my preferred solution is a JavaScript-based one. I have tried JavaScriptSpellCheck and it works okay, though I would like to see what some of my other options may be. I also found spellchecker.net but at $3500 for a server license it seems excessive.
Spell checking can be in a separate window and must support multiple languages (the more the better). Ultimately I would like to send the spell check object a collection or delimited string of textarea names or id's (preferably names as they already exist in the pages) and have it spell check all of them, updating the text as spelling is corrected.
Check out using Google's api for this: http://www.asp101.com/articles/jeremy/googlespell/default.asp
Here is a free, open source Javascript library for spell checking that I authored:
https://github.com/LPology/Javascript-PHP-Spell-Checker
There's a link to a live demo at the top. It's designed to have the feel of a spell checker in a desktop word processor. I wrote it after being dissatisified with these same options.
To use, just include the JS and CSS files into your page, and then add this:
var checker = new sc.SpellChecker(
button: 'spellcheck_button', // opens the spell checker when clicked
textInput: 'text_box', // HTML field containing the text to spell check
action: '/spellcheck.php' // URL of the server side script
);
It includes a PHP script for spell checking, but it could be ported to another language fairly easily as long as it returns the correct JSON response.
If I were you, I'd look into something like aspell - this is used as one of the supported spellchecking backends in TinyMCE. Personally, I use pspell because it's integrated into PHP.
EDIT
There's an aspell integration here that has a PHP or a Perl/CGI version; might be worth checking out.
If I am not wrong, Firefox's English dictionary for spell checking takes around 800KB of data.
If you like to do everything in JavaScript -- for a full-featured spell checking engine, it means you need to load that 800KB data in every page load. It's really not a good idea.
So, instead of doing that in JavaScript, send the data to the server with AJAX, check it server side, and return it back; that's the best way.
Well this is quite old question, but my answer might help people who are looking for latest options on this question.
"JavaScript SpellCheck" is the industry leading spellchecker plugin for javascript. It allows the developer to easily add and control spellchecking in almost any HTML environment. You can install it in about 5 minutes by copying a folder into your website.
http://www.javascriptspellcheck.com/
Also support multiple languages - http://www.javascriptspellcheck.com/Internationalization_Demo
I might be a bit late on the answer to this question. I found a solution a long while ago. You must have a spell checker installed on your browser first. Then create a bookmark with the following code as the link.
javascript:document.body.contentEditable='true'; document.designMode='on'; void 0