New answers tagged javascript
2
Yes, what you're saying makes sense.
By setting your cookie as an HttpOnly cookie, you're mitigating the risk of your partner's JavaScript having access to the user's session ID. Since your partner insists on getting a unique identifier for your customers, I see nothing wrong with sending them a securely hashed version of the session ID.
The key point here ...
-1
Looks like the simple solution (i.e., CSRF protection but with all-cacheable web resources) is to just add a separate cookie containing the anti-CSRF token but accessible to page javascript.
In other words, when the client logs in, I'll actually set two cookies (one HttpOnly sessionid and one non-HttpOnly anti-CSRF token, accessed by page scripts). So, the ...
6
The Same Origin Policy for DOM access isolates sub-domains, therefor the impact of XSS is isolated to a specific sub-domain. The Same Origin Policy for Cookie scope isolates sub-domains in that they cannot read or write another sub-domain's cookies. Just make sure your main site is www.site.com and no cookie is scoped to *.site.com, as this would be ...
2
Allowing user entered Javascript is pretty much the definition of Cross Site Scripting (XSS).
The story of the Samy Myspace Worm is a great illustration of what can happen when a user can upload Javascript onto your site. Myspace wanted to allow sanitized HTML, but the hacker found a way to get around it. He put some Javascript in that caused anybody ...
1
The problem with this implantation is that the CSRF token is not actually stored within an anonymous function. This token would be stored within text that declares an anonymous function. An XSS payload can request this text from the server using an XHR, the CSRF token can be read and another XHR can be used to send an arbitrary forged request.
Related: ...
2
The only time that you need to worry about the token being read is if there's a malicious extension or an MITM attack being carried out.
In both cases, it's no longer a CSRF problem. Both attacks have the capability of catching the request on the fly (after your javascript has assembled it with the token) and modifying it. This isn't CSRF, but it's still a ...
2
I have yet to encounter any security best practice that says "All JS scripts should be omitted when presenting web pages with personal/credit card data".
Is there a way to hack your JS Widget in such a way as to pose a threat if the widget and customer credit card data are on the same page? Maybe. You'd need to really review the widget, and how it can ...
0
To me, there are no inherent risks to allowing the widget on a CC processing page. There are many sites that have various snippets on these pages (like Google analytics). Your code doesn't have access to the CC information on the form unless it's coded to do so anyway, plus the code's should be on their server anyway so it couldn't be modified maliciously.
3
If I understand correctly, you are trying to proactively protect your clients from the perception of potential risks by suggesting that your own code should not be run on certain pages. Your efforts might not be necessary.
Let your clients protect themselves by letting them choose for themselves. Alter your documentation to say, "install on every page, but ...
0
As mentioned by a number people - double submit is an ok CSRF protection, provided that you use a separate nonce. Using session id is very wrong in this context, starting with the fact that sessionid has to be HTTPOnly for XSS protection.
An argument of "what if there is XSS on this page/website" is not valid - when you have XSS, CSRF is the least of your ...
2
There is no interface to SSL authentication (either server-client or client-server) from JavaScript. It is all dealt with by the browser UI.
On IE, you may be able to use the CertEnroll (previously XEnroll) ActiveX control as a way to get a newly-generated key into the user's keystore; otherwise you would just have to require them to install the certificate ...
1
First of all, CSRF attacks do not require any JavaScript at all. You can forge arbitrary requests with pure HTML to send arbitrary GET or POST requests via simple images or simple forms.
JavaScript would only be helpful to automatically send the latter forms as are not send automatically like a request for an image would. But you could also style the form’s ...
4
Most ecommerce sites include google analytics code on payment pages. Payment pages are also a prime candidate for a/b testing using JS tools such as optimizely or visual-website-optimizer.
There are also integrations to third-party product subscription engines that rely on JS passing CC data from the cart back to the service's mother ship (e.g. ...
2
Yes, they are blind. The same-origin policy prevents pages hosted in one domain using one protocol [and sometimes also port] to making arbitrary requests to a different domain/protocol. So, one attacker would not be able to make a "CSRF Ajax request" unless your server supports CORS. What makes CSRF attacks possible at all are the exceptions for the ...
4
The Same-Origin Policy makes it impossible for JavaScript on A.com to read content from B.com. However, Same-Origin Policy does not prevent JavaScript or HTML on A.com from sending an arbitrary request to B.com. In order to prevent this, you need a method of CSRF Prevention, such as a secret token which would not work if the system wasn't blind.
The ...
1
You could, but it seems a bit unwieldy to me. Any CSRF-prevention mechanism works like this:
Make the server only accept requests that satisfy some conditions
Ensure that the conditions are something that can't be forged
Write your HTML so that the requests it generates follow the conditions set by the server.
The tried-and-tested method is to use ...
14
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 ...
10
No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website.
To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.
1
Of course this is a baseless fear.
Javascript is only one part of a larger ecosystem, much more important is brand, site usability, site integrity, responsiveness and network effects.
Yeah, javascript minimisation, optimisation is good to do, but not because of these purposes.
If a competitor steals you code, you can go legal on their tails, and kill ...
1
Using window.confirm() is a valid method of mitigating Clickjacking when it is not possible to use x-frame-options. This popup window cannot be framed. In every browser except for Internet Explorer the origin of the confirmation window is displayed if the domain differs from the parent iframe in the popup because of Clickjacking. The use of ...
6
I think the operative word in the question is "afraid." The aversion is based on fear, not fact. The reality is, the threat model isn't particularly realistic. Commercial web software development companies nearly universally use JavaScript these days, obfuscated or otherwise, and I challenge you to find me even a single example of one that's had it's JS ...
3
You seem to already know that obfuscation isn't actual protection, so I'm not gonna lecture you on security by obscurity.
What makes sense is this: Put your competitive code on the server to protect it, then obfuscate client-side code as much as you want. Granted, it won't give you much security but it'll definitely deter kiddies snooping around, and it'll ...
2
No. Obfuscating Javascript usually makes no sense whatsoever. Always assume that any logic you place on the client side can easily be obtained by a determined enough attack no matter how you obfuscate it.
Your "important" logic should be stored server side.
3
Let's illustrate how a basic page request works:
Request
index.php
#4 Processing |--------| 1#-----------> |--------| #2 Processing
HTML/CSS/JS | Client | | Server | the requet
etc... |--------| <-----------#3 |--------|
Sending
...
3
The server does not parse JavaScript except under very specific circumstances (i.e. you run NodeJS and you eval() a user input. Someone would have to be bloody stupid to do that or have a very valid reason to do so). So, the server does not see/care about the actual content of the code, and it won't be executed server-side. The reason for something like ...
2
As a rule of thumb, never trust user input, even if you're confident it'll only come from authenticated users. If any of your CGI scripts are internet-facing (i.e. can be executed as a direct consequence of your users requests, be them the jQuery ajax calls or regular page access), you should sanitize all input fields and check proper authentication and ...
3
If a user's browser is able to call (send HTTP request to) your Python scripts (with or without AJAX), then assume that an authenticated user will be able to send custom HTTP requests, including whatever variables (parameters) they want.
Always assume that not only your users are able to see your JavaScript code, but they're also able to modify it, override ...
1
AngularJS Batarang seems to be the tool you might be looking for. It's a Chrome Developer Tools extension that adds support for debugging and profiling AngularJS applications.
Other than that, you could also inspect values the standard way by accessing DOM element values by JavaScript. It might be a bit tricky to get a pointer to the exact element in ...
2
The difficulty with these sort of code injections is that if you are using a hosted service provider is it possible for the infections to spread between the various clients hosted. It may not be your actual installation of WordPress that is the problem.
Another thing you can ensure is that all of your plugins and your WP is up to date. Following the ...
4
How could the JavaScript that redirected the users be injected into the DOL's site in the first place?
From a cursory reading, it appears that the vulnerability is a simple XSS attack.
What technology was used the exploit the memory vulnerability in Internet Explorer (i.e. JavaScript, JAVA, Flash, etc)?
It appears to be a Javascript-only attack. ...
5
A jailbroken iPhone or "rooted" Android device is not qualitatively distinguishable from a desktop system. From the server side, you cannot know whether the device is rooted or not; or even if it really is the device you believe it is to be. Whatever issues Javascript-based crypto can have on "desktop" systems also apply to mobile platforms. Of course, any ...
2
This is what I understand from your question.
You accept a password at the client side
You random pad the password.
You hash the password at the client.
You encrypt the hash using the public key of the server
You send the encrypted hash to the server
Server decrypts the hash using it's private key & compares it against it's stored hash to check the ...
6
Firstly, I'm assuming that you're doing this to weaken man in the middle attacks (which really are the only problem when it comes to plaintext passwords over insecure HTTP)
Client side hashing has little to no benefit. An attacker, on picking up the hash will not need to brute force the hash. All your server needs is the hash, so the attacker can simply ...
Top 50 recent answers are included
