Twelve rules for developing more secure Java code-Rule 5

Rule 5: Don't use inner classes

Some Java language books say inner classes can be accessed only by the outer classes that enclose them. But this isn't true. Java bytecode has no concept of inner classes, so inner classes are translated by the compiler into ordinary classes that happen to be accessible to any code in the same package. And Rule 4 says not to depend on package scope for protection. 

But wait, it gets worse. An inner class gets access to the fields of the enclosing outer class, even if the these fields are declared private. And the inner class is translated into a separate class. To let this separate class access the fields of the outer class, the compiler silently changes these fields from private to package scope! It's bad enough that the inner class is exposed; but it's even worse that the compiler is silently overruling your decision to make some fields private. Don't use inner classes if you can help it. (Ironically, the new JDK 1.2 PrivilegedAction API requires you to use an inner class to write privileged code. For more details, see our book Securing Java and the developer.com article referenced below.) That's one reason we don't like the PrivilegedAction API.)

How to Call Procedure without Callable

package org.best.example;
import java.sql.*;
    class ProcedureCalling {
         public static void main(String args[]){
             try{
             Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
             Connection con=DriverManager.getConnection("jdbc:odbc:test1","sa","password");
             String sql= "{ call procname(?) }"; // procname is name of procedure
             cst=con.prepareCall(sql);
             int i=1;
             cst.registerOutParameter(1,Types.NUMERIC,0);
             cst.setInt(1,i);
             cst.executeUpdate();
             i=cst.getInt(1);
         }catch(Exception proc)
             { System.out.println("error ine executed query is :" + proc);
     } }
}
}

How to Execute system commands in a Java Program

Most often in your Java programs you will find a need to execute system DOS commands. You can execute any system commands that are OS specific and then read the output of the system command from your Java program for further processing within the Java program.
This sample Java Program executes the 'dir' command reads the output of the dir command prints the results. This is just for understanding the concept, however, you may execute just about any command using this Runtime.getRuntime().exec() command.

package org.best.examples;

import java.io.*; 

public class doscmd 
{ 
public static void main(String args[]) 
{ 
try 
{ 
Process p=Runtime.getRuntime().exec("cmd /c dir"); 
p.waitFor(); 
BufferedReader reader=new BufferedReader(new InputStreamReader(p.getInputStream())); 
String line=reader.readLine(); 
while(line!=null) 
{ 
System.out.println(line); 
line=reader.readLine(); 
} 

} 
catch(IOException e1) {} 
catch(InterruptedException e2) {} 

System.out.println("Done"); 
} 
} 

Twelve rules for developing more secure Java code-Rule 4

Rule 4: Don't depend on package scope

Classes, methods, and variables that aren't explicitly labeled as public, private, or protected are accessible within the same package. Don't rely on this for security. Java classes aren't closed, so an attacker could introduce a new class into your package and use this new class to access the things you thought you were hiding. (A few packages, such as java.lang, are closed by default, and a few Java virtual machines (JVMs) let you close your own packages. But you're better off assuming packages aren't closed.)

Package scope makes a lot of sense from a software-engineering standpoint, since it prevents innocent, accidental access to things you want to hide. But don't depend on it for security.

Maybe we'll get sealed classes in the future.

Twelve rules for developing more secure Java code-Rule 3

Rule 3: Make everything final (unless there's a good reason not to)

If a class or method isn't final, an attacker could try to extend it in a dangerous and unforeseen way. By default, everything should be final. Make something nonfinal only if there is a good reason, and document that reason.

You might think you can prevent an attacker from extending your class or its methods by declaring the class nonpublic. But if a class isn't public, it must be accessible from within the same package, and as Rule 4 (below) says, you shouldn't to rely on package scope access restrictions for security. 

This advice may seem harsh. After all, the rule is asking you to give up extensibility, which is one of the main benefits of using an object-oriented language like Java. But when you're trying to provide security, extensibility is your enemy: it just provides an attacker with more ways to cause trouble.

how to Insert an Image into SQL Server

package org.best.example;

import java.sql.*;
public class InsertBlob_SQLServer
    {
     static Connection conn = null;
   
     public InsertBlob_SQLServer()
         {
         try
             {
             Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
             conn = DriverManager.getConnection("jdbc:odbc:javaxxx", "userid", "pwd");
         }
         catch(Exception e)
             {
             e.printStackTrace();
         }
     }
     public static void main(String[] args)
         {
         InsertBlob_SQLServer insertBlob1 = new InsertBlob_SQLServer();
         if(args.length != 2)
             {
             System.out.println("Usage: java InsertBlob_SQLServer FileName File");
             System.out.println("Example: java InsertBlob_SQLServer myImage.jpg \"C:\\\\MyFolder\\\\myImage.jpg\"");
         }
         else
             {
             try
                 {
                 insertBlob1.insPic(conn, args[0], args[1]);
             }
             catch(Exception e)
                 {
                 e.printStackTrace();
             }
             finally
                 {
                 insertBlob1 = null;
             }
         }
     }
   
     private void insPic(Connection c, String name, String fName)
         {
         try
             {
             File f = new File(fName);
             FileInputStream in = new FileInputStream(f);
             byte[] image = new byte[(int) f.length()];
             in.read(image);
             // Below: the question marks are IN parameter placeholders.
             String sql = "INSERT INTO testImage VALUES(?,?)";
             PreparedStatement stmt = c.prepareStatement(sql);
             stmt.setString(1, name);
             stmt.setBytes(2, image);
             stmt.executeUpdate();
             stmt.close();
         }
         catch (SQLException e)
             {
             System.out.print(e.getMessage());
         }
         catch (IOException e)
             {
             System.out.print(e.getMessage());
         }
     }
}
//create table testImage(fname varchar(100),img image)

Twelve rules for developing more secure Java code-Rule 2

Rule 2: Limit access to your classes, methods, and variables

Every class, method, and variable that is not private provides a potential entry point for an attacker. By default, everything should be private. Make something nonprivate only with good reason, and document that reason.