New answers tagged

1

You're trying to do the impossible here. You're having the localhost server authenticate the client application running in the browser. This is impossible to do securely. What you would want is to write a browser plugin/add-on. The browser plugin/add-on should only activate itself when visiting authorized sites.


6

The IV is a random non-secret value. Its sole purpose is to prevent two similar blocks from yielding the same ciphertext as it could give information away about the structure of the plain text. In general you just generate the IV randomly and concatenate it to the ciphertext. The IV must be of the same length as the block for AES-CBC, which is 128 bits. You ...


0

Your understanding about AES is correct, it came into PDF in version 1.6 (see section 3.5 of PDF Reference v1.6 for details). PDF 1.6 and 1.7 (and ISO 32000-1) support AES in 128-bit mode. Adobe's ExtensionLevel 3 for PDF 1.7/ISO 32000-1 introduced AES in 256-bit mode but should be avoided because of weaknesses in the password mechanism. Better support was ...


1

This is the code I'm currently using: if(!url.getProtocol().startsWith("http")) throw new Exception(); InetAddress inetAddress = InetAddress.getByName(url.getHost()); if(inetAddress.isAnyLocalAddress() || inetAddress.isLoopbackAddress() || inetAddress.isLinkLocalAddress()) throw new Exception(); HttpURLConnection conn = (HttpURLConnection)(url....


0

You may want to disable the payload handler set payload to custom_exe and set custom::exe /custome.exe This should get it done. You also have to keep in mind that the depending on what the exploit is doing, and how much memory space is is using, or rather how much memory space you have to execute shellcode, you may not be able to use a custom exe with ...


0

Giving an app your OAuth token is kind of like giving them a limited-use password. In this case it's a password they they can use to get into your Google Drive, but they can't use it to get into your Gmail. If you're not comfortable with the app saving that key to storage, then don't use that app. Also, you can review which OAuth tokens you've granted and ...


2

I believe you're asking the wrong question. The right question is "Should someone new to security be working on a root CA?" and the answer is "probably not." It is highly likely that what you're doing will expose everyone who relies on your root CA to high risk of compromise. This has been demostrated by mature companies like Dell (see, for example, http:/...


2

Yes, you can crank up Tomcat logging to include that information using the javax.net.debug system property. That will allow you to get this sort of output, which includes the cipher suite proposed by the client: *** ClientHello, TLSv1 RandomCookie: GMT: 1073239164 bytes = { 10, 80, 71, 86, 124, 135, 104, 151, 72, 153, 70, 28, 97, 232, 160, 217, 146, 178, ...


0

Why not just load the java_atomicreferencearray exploit using the metasploit-framework? msfconsole use .*java_atomicreferencearray <tab> info show missing set <stuff> options check exploit -j Then just point your vulnerable JRE-enabled browser at the listener URL it provides.


0

Yes, the list of supported ciphers are sent by the client, so the server could perfectly log which are offered by the client. It may be a bit harder (and will depend on your particular implementation) to access them, as that's typically abstracted in the SSL layer.



Top 50 recent answers are included