Arshad Noor

Ranch Hand
+ Follow
since Oct 06, 2011
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Arshad Noor

I attended an OWASP presentation yesterday in Silicon Valley, and was dumb-founded to learn that SQL Injection is still the #1 problem for web-applications in 2012. Not sure how many years it has been since OWASP put this on its list of Top 10 vulnerabilities - I definitely recall reading about it in 2005 - but hearing that this is still the #1 problem, is simply incredible.

The Java Enterprise Edition, IMO, has the optimal architecture to permanently eliminate this problem: the web-form talks to the servlet, the servlet hands over the form-data to a stateless session-bean, which, based on the parameters it parses and validates, calls the appropriate entity-bean to execute the OQL query and hand the results back to the SLSB. Even if the attacker was clever enough to get past the data-validation in the SLSB, what can an attacker do with SQL embedded inside an OQL parameter?

Does the book recommend ways to eliminate this problem once and for all? Even if business executives are idiots who do not provide sufficient time/resources to get the job done right, I would imagine books and experts should have spread enough information by now, to make a SQL Injection vulnerability a career stigma for any programmer. TIA.
Anytime you have a client-server application that gives you problems, supplying just the client-side error message rarely helps you get an answer. Have you looked at the server's log to see what error is reported? If you cannot make out what the error means, post the server-side error message on the forum; you might get a solution or a pointer to the solution.

Arshad Noor
StrongAuth, Inc.
12 years ago
We stopped using commercial software more than 10 years ago in our business (with the exception of two minor, little-used products for accounting and image-manipulation). We've built our company on open-source and only produce open-source software; so, unfortunately, I cannot provide you any information on commercial software that provides equivalent value to FOSS.

Arshad Noor
StrongAuth, Inc.
12 years ago

- the conclusion is, that I have to import the certificates into cacerts instead of using my own keystore called myCompany.jks?



If you want it to consistently work without specifying any -D options for specific keystores/truststores, then yes, you should pull the trusted CA cert into the "cacerts" file. Alternatively, you can keep it in your custom file, but consistently specify the location of the keystore/truststore on the command-line that starts the JVM; see this thread for more: https://coderanch.com/t/561288/Security/javax-net-ssl-keyStore-javax.

Arshad Noor
StrongAuth, Inc.
12 years ago
This appears to be an IBM-specific technology, as opposed to a generic Java capability; have you tried contacting your IBM support people for help?

Arshad Noor
StrongAuth, Inc.
12 years ago
@Srikanth - what are you trying to do from a business perspective?

Arshad Noor
StrongAuth, Inc.
12 years ago
Have you installed the JCE Unlimited Strength jar file?

Arshad Noor
StrongAuth, Inc.
12 years ago
It depends on a lot of factors.

There is nothing wrong with an application specifying a single keystore/truststore with only one certificate as a trusted certificate in it for the entire JVM, as long as anyone using that JVM recognizes that its keystore/truststore is customized. This is a much more paranoid setting than the default which trusts more than 50 Certification Authorities all over the world.

Generally, an application's security review determines what must be trusted, what other applications are running on the same machine and do they need to use the same JVM, etc. Once you've reviewed these, there are many different ways to configure this.

1) You can create different keystores/truststores for each applications and specify these properties on the command line that starts the JVM with the -D options (see http://docs.oracle.com/javaee/1.4/tutorial/doc/Security6.html for explanation). Now each application will start its own JVM with its own keystore/truststore;
2) You can create a common keystore/truststore and have all the applications on the machine use the same *stores when they start the JVM; this assumes that they all have the same security profile and its OK for them to be sharing these resources;
3) You can write the code manually to read your own keystore/truststore and establish your own SSL session without use the System properties; this is harder and more work, but it will work for those who are super-paranoid;
4) There may be other ways, but I would usually pick a solution from either #1 or #2.

Arshad Noor
StrongAuth, Inc.
12 years ago
Have you considered asking the developers of WSS4J on their User list? They are likely to give you the most definitive answer.

users@ws.apache.org

Arshad Noor
StrongAuth, Inc.
12 years ago
I have not personally tested the J2SE's OCSP Responder code, but I have no doubt that it should work if the configuration is correct.

Setting just "ocsp.enable" to "true" and expecting it to work implies that you have a full-blown OCSP Responder environment and that your certificates have the appropriate extensions (AIA) in them that provide all the information necessary for the OCSP code in J2SE to work. If the digital certificate does not have the extension, or if any of the values are incorrect or missing, then it is obviously not going to work until you explicitly specify all the other OCSP parameters specified.

Arshad Noor
StrongAuth, Inc.
12 years ago
Every X509 v3 digital certificate will have a certificate extension called SubjectKeyIdentifier (SKI). This is a hash (usually MD5 of SHA1) of the raw public key in the certificate. Compare this hash to the hash found in the SKI extension of the certificate in the JKS file. If the hashes match, they are the same public key.

Note that even if the hashes of the public-keys match, they are not likely the same certificate - just the same key. Depending on how the certificate was created and who issued it, the digital certificates could have completely different Subject DNs, key-usages, etc. If you need to determine if the certificates are identical, then you need to match up the Issuer DNs, the Subject DNs, the AuthorityKeyIdentifier (AKI) values, the SKI values and certificate serial numbers before you can determine that they are the same certificates.

Arshad Noor
StrongAuth, Inc.
12 years ago
This sounds like any other application that might need to secure access to content based on appropriate authentication and authorization. The only difference appears to be that you want to stream live video instead of static data from a database.

Approach it like you would any database application, with all the required access controls, and then based on the authenticated user's authorization, show them whatever video streams they're authorized to see. SSL/TLS will handle all the encryption you need on the wire. There are probably hundreds of books on the subject, but you can't go wrong just reading the free JEE6 Tutorial at java.sun.com and following the example there.

Arshad Noor
StrongAuth, Inc.
12 years ago
Are you saying that Tomcat restarts by itself every day? Or do you explcitly restart it for some reason?

Regardless, trusted CA certificates may be in one of many places: i) the cacerts file from JAVA_HOME/jre/lib/security; ii) application-specific keystore.jks files; or iii) any file of your choice.

When the CA cert is imported using keytool into cacerts, the certificate is trusted by ALL applications that use that JVM.

When the CA cert is imported using keytool into a specific keystore.jks file, the certificate is trusted by that specific application using that keystore; in your case, it would be the Tomcat application.

When the CA cert is imported using keytool into a filename of your choice, the certificate is NOT visible to anything unless you specify options on the command-line to Java that it should use the custom file with the CA cert in it.

As for the file stored as Filename.crt in the JAVA_HOME/jre/lib/security folder, it does nothing. Unless you've created some application or script that automatically imports files with a .crt extension into the cacerts file each time you restart. That might explain the bizarre behavior you're seeing.

Arshad Noor
StrongAuth, Inc.
12 years ago
Isn't this question more appropriate on the WebSphere forum at IBM (if there is one); if not, given that AA has probably paid for it, you should call IBM support for the answer. This is not a JDK/JCE-specific error.

Arshad Noor
StrongAuth, Inc.
12 years ago
I would strongly recommend reading this white-paper from Mozilla's website; it is one of the best introductions to Public Key Cryptography I have seen in 12+ years: https://developer.mozilla.org/en/Introduction_to_Public-Key_Cryptography.

Once you've done that, for testing purpose, use keytool - which is part of the JDK - and generate your own certificates: client and server. And then follow the instructions provided by Microsoft to configure the server certificate for the DB along with the ClientAuth option turned ON. Use the client certificate with the tool you want and then test your connection. If you've done this correctly, you should have a secure connection between the client and the server.

If this DB serves only an internal application, then you can continue to use the keytool-generated keys/certificates without having to buy one from any Certification Authority.

Arshad Noor
StrongAuth, Inc.
12 years ago