Tag Info

New answers tagged

1

Yes, if a path containing script tags is resolved to the page containing this code on your server (for example, via a rewrite rule) then script could be rendered in your page. This will be DOM based XSS as it will be your client-side code that is adding the script tag. e.g. https://www.example.com/foo/bar/<script>alert('foo')</script>


0

I also believe that the Double Submit Cookie pattern is discouraged because it requires setting the cookie HTTPOnly value to False It doesn't require setting HTTPOnly to false. This is only if you have some JavaScript code that will set the hidden form field value to the same as the cookie. It is possible to do this without JavaScript by simply ...


6

Try BeEF framework, It is specifically useful for a wide range of web browsers and has tested methodologies. Once the main javascript file is loaded in the client browser(Through cross site or any other means), an attacker can perform full control of the client system depending upon the available browser specific exploits.


13

If you are looking for malware to study and understand how it works metasploit is great. The framework is open source so you can study how it works. You can search the metasploit database. I'm not sure what exactly you're looking for when you say "JavaScript Malware" but if you mean JavaScript that could compromise users who view a site CVE-2012-3993 ...


3

The OWASP XSS Experimental Minimal Encoding Rules suggest that all that needs to be encoded are <, & and >, as long as the charset is specified. Assuming the second page outputs within an HTML context, then there doesn't seem to be an XSS attack vector in this case. Setting charset and then encoding your POST will simply mean that the server will ...


13

JavaScript, the Definitive Guide, 4th Edition - published in 2001 - mentions these in a bit more detail. The relevant section appears to be freely available. It's right at the bottom of that link. Here's the excerpt: 12.2.5. JavaScript in Nonstandard Contexts Both Netscape and Microsoft have implemented proprietary extensions in their browsers, and ...


2

To see an explanation of typical methods of exploiting Javascript, it would be better to get a book on the subject, rather than rely on fragmentary answers here. There are many such books, for example: "The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws" by Dafydd Stuttard, and Marcus Pinto. "XSS Attacks: Cross Site Scripting ...


0

DOM XSS are as dangerous as reflected XSS. To exploit it the attacker always needs to induce a client to create a request (f.e. by clicking some link that still points to the considered safe site). After this has been done, you can execure JavaScript on the client's browser. This can lead to all sort of attacks on the browser!


0

Most of the Vulnerabilities in the browsers are in the complex parts, such as the dynamic DOM-tree building. This is something that Javascript does, when a programmer makes a mistake (such as a use-after-free) people can exploit this. And by writing specific javascript you can groom the heap to hold the exact values you need to make the browser do what you ...


1

I hate those kind of problems. There are so many places something could have happened. I think I would just double check my config files - always a good idea to have a copy of valid config files. I use a GIT based tool to version all of mine. Then you can easily spot any unknown changes and back them out. Then I would add the domain to IPTABLES and block ...


1

There are many possible attacks, which all depend on the JS engine, the available API and the execution environment. JS is a language after all even though I suspect you only are interested in the Web uses. I know next-to-nothing about Web security, but for instance JS is also part of the PDF format 5 years ago you could load DTD's in a XML document in your ...


1

To make a random, unbiased shuffle, you apply the Fisher-Yates algorithm. If you want to shuffle an array x of n elements (numbered from 0 to n-1), you do this: for all i from 0 to n-1 let j = rnd(n - i) + i swap x[i] with x[j] where rnd(k) means: generate a random uniform value in the 0 to k-1 range. Note that it may happen that i = j in the loop ...


0

The Javascript is running on your browser, not "on a site". Your browser is doing everything. You can access their DOM, but that's alright, because you are only seeing content which has been sent to your browser. You can't see other user's data or any of the server internals. Also, the browser has a number of builtin limits and throttles. I believe the ...


0

John Downey has given the best answer but just to expand on the biggest problem with this part of the workflow: Make the merchant generate a private and a public key Store the private key inside his browser using localstorage So, lets say you have a dozen merchants with public and private keys stored in their browsers. You don't store their ...


1

If you're storing the card data on your own servers, even if it's encrypted and you don't have the key to decrypt it, then you need to comply with the most elaborate version of the PCI standards and use SAQ-D. I would suggest that you don't store the card data at all, but get the merchant to store it for you. Then you should only need to use SAQ-C.


0

If your intention is to gain assurance that no malicious alterations have been made to your script as part of a whitebox code security review you are looking for two things: Any monitoring of keyboard events Any reads from the DOM As mentioned elsewhere - ultimately someone will be trying to exfiltrate the data. At this point you are looking for: Any ...


1

There are many 3rd party payment processors that allow you to transparently use their forms and processing - including paypal, google, worldpay, and many others. This can be pretty much transparent to the user if configured correctly. This is the best way of side-stepping the PCI requirements - never process any of the card information... There are some ...


4

(Disclosure, I work at Braintree) If a server is providing a form that customers will enter credit card numbers into then that server falls within PCI scope. This is regardless of if you encrypt the data in the browser. The reasoning here is that an attacker can modify the page that is sent to the browser to siphon credit card data out of the page DOM ...


3

A quick way I would assess a site would be to run a VM with a network monitor on and monitor what is being sent from the site (and to where). After all, an attacker somehow needs to collect those logged data points. If nothing shows up, I'd then go into the code itself. I'd use a javascript debugger and see exactly what functions were being fired when I ...


8

In order to do any damage to your computer or data stored on it, the page would have to either exploit a security vulnerability in software on your computer or prompt you with an additional confirmation dialogue. The warning may be due to the page exploiting a security vulnerability for which there is not yet a patch available, so the warning should be ...


3

Yes, no, maybe so. There are a couple major things in play here. Javascript is a full fledged programming language. This did not use to be the case in it's infancy as a crutch for DHTML (Dynamic HTML, whatever that was!). As a full fledged language with a full blown interpreter/compiler it is really no different than other most other languages software is ...


5

The threat a virus impose in your system is, ideally, independent of its programming language because viruses exploit vulnerabilities in operating systems, applications, APIs etc. In this sense, a Javascript virus is as dangerous as any other virus. Also, for web applications, JavaScript is one of the main attack vectors in techniques such as cross-site ...


2

"Too dangerous" is very subjective of a term. It really depends on what the JS is being used for. JS is merely a tool. The most common (and perhaps most damaging) is called a cross site scripting attack where malicious JS redirects traffic. This traffic can be spoofed and therefore appear as trusted/secure but it really isnt. Thus, I say this attack is ...


19

Yes there are known attacks of this type. The site you are trying to visit is one. That's why your browser is telling you not to visit the page. Javascript files included on pages are always executed by the browser. That's what Javascript does. Whether or not it has the necessary privileges to do something malicious is where the battle is at. It is unlikely ...


7

When you use a re-webber proxy (a website where you enter a URL and it shows you the content of that url in its own context), using TLS between you and the end-website becomes impossible, even when the proxy would want to provide it. When you enter https://google.com in the proxy you linked, you get redirected to ...


0

Aside from possible flaws with SSL, you can make sure the certificate belongs to the site you're visiting. If SSL is secure, then your data should be secure as well. I'm not too certain on the feasibility of faking certificates, but generally what I've read is if it's signed by the proper authority then it's real. I would do some research first, although I ...



Top 50 recent answers are included