Security and object oriented programming..

I just started a class dealing with object oriented programming....

In my younger days, I used to spend a fair amount of time "cracking" nag screens, time trials, etc. The reason I was able to do so (with relative ease in some cases) was because when programs were compiled, sometimes they left little loopholes that the developers didn't catch, or didn't realize were happening... and it was usually something simple like:

cmp eax,eax
jmp if not equal, blah, blah, blah

Our instructor (and the films we have watched) have made a big deal about ease of use, compatibility, etc... (I realize it's a lot of propoganda)

Since Java is a compiled language, how is it for programming secure applications? Any thoughts? Does it leave similar holes? Is that just the nature of any language that has to be compiled?

Java is a compiled language, yes, but it it compiled for the JVM machine language, not for x86, so the operatrions are somewhat different. It could still be exposed to similar holes, however I'm not sure if it is or not. Google would likely be able to answer your question.

Also, your thread title was incredibly misleading...

1. I did google, but wasn't able to find a satisfactory answer.

2. I'm not sure how much better a title I could have put on it other than something incredibly long that wouldn't have fit in the title window... what would you suggest? :rolleyes: Do you get offended when people title their threads "help" or "I need help right away".

3. Before anybody else gets their panties in a wad, I have been considering development of a couple applications for the company I work for that would retrieve paperwork from a secure server... since I happen to be enrolled in a programming class, I wanted to explore potential issues before I even started.

4. I know nothing about programming, so just looking at some code tells me nothing... but to each his own I guess... I forgot my E.S.P. pills this morning. :D

While I'm sure that people are going to have a problem with you using Java synonymously with OOP, there are a good deal of security related features in Java. For instance, when you program in java you will notice that variables can be declared as public, protected, and private. This is done to protect variables in a class from unwanted manipulation. You'll notice that many Java programmers have a tendency to declare all of their variables as private, and then control access to them from getter and setter methods. A public variable can be manipulated from another class by any means that it sees fit. A protected variable can only be read but not changed, and a private variable can't be accessed directly at all. Lets say that we have a variable called "water" in our class "pool". You could declare two variables:

Code:

---

final int CAPACITY = 5000;
private int water = 0;

---

You'll notice that the variable CAPACITY has the keyword "final" in front of it. This, in a sense is even more secure than private, becuase it means that the variable CANNOT be changed, and I tend to use it for constants as one might use #define in C. water has been declared as private. By declaring the variable as private, we limit access to it through a method like:

Code:

---

public void addWater(int amount) throws Exception {

if ((water + amount) > capacity)
      throw new Exception("Adding " + amount + " would cause the pool to overflow!!!");
else
    water = water + amount;

}

---

if water was a public variable other classes could add to it as they pleased with results that could be disatrous to the program. Now, inadvertantly I've touched upon another facet of secure Java programming in my example above. If you're not terribly familiar with Java you might be saying "throws Exception?? What the hell does that mean?"

Exceptions are probably the most common way of making your Java code behave the way you expect, and you won't get too far in Java programming before you encounter a method that throws one. An Exception is an event that is generated when code encounters a certain case that the author has deemed exceptional.

Sun's official definition is "An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions. "

In this case, we generate an exception when the amount of water that the user, or parent class, tries to add to the pool is greater than the overall capacity. In order to use a method that generates an exception in your code, it must be done inside of what is known as a try/catch/finally block. Here is an example using our addWater method above.

Code:

---


.....code leading up to addwater call.......
try{
      addWater(userDefinedAmout);
    }
catch(Exception e) {
    System.out.println(e.getMessage());
}
finally{
    //Clean up code if neccessary
}

---

As you can see, before you use a method that throws an Exception, you must enclose the code in a try { } block. After you close out the try block, you follow it up with the catch{ } block. This defines what your program will do if the method it called throws the Exception. Many times it is acceptable to print an error message to standard out along with a Stack Trace if neccessary, but very frequently you may find yourself redirecting the entire functionality of the program when an exception is encountered. Be creative, learn to see Exceptions as a tool to regulate the flow or your program and not just as glorified Errors. The finally block is not required but is often used to perform certain cleanup operations and is garunteed to be executed even in the event of catastrophic faliure of your program....I think.....I never really use it.

I'll definitely post more when I've got the time, but I have to get back to work.

Thank you... that explained things sufficiently, and I appreciate it. I hope others take note of the effort ;)

erm, I think there is some misinformation in vicc's post.

Java itself is a decent enough language, but as with any language there are quirks and concerns you must pay attention to when it comes to your project.

Firstly there is it's compilation to byte code. Byte code is easier to decompile and figure out than code compiled directly to binary. It is the same problem .net code suffers from when it is compiled to IL.

Examples of such can be found here : http://www.google.com/search?hl=en&i...compiling+java

As far as access qualifiers (public, private, protected) that does not have to do with the object in question being read only or not. Public is open to anyone, protected is open to members of the same package, and private is only accessible from the same class. This does leave you open to unwanted manipulation or information gathering from members of the same package. This also can depend on the object in question...

You use the accessor methods you develop to control whether the variable is read only, that the data type is valid, etc.

For more info : http://cs.stmarys.ca/~porter/csc/ref/java_access.html

A good portion of the java security problems in the past have to do with remote method calls using goods such as RMI. Another good source of problems is the class loading mechanism.

You also have to be aware of the language quirks such as java strings being immutable. Therefore if sensitive data is being held, you more than likely want to favor a char array over an actual string since you cannot explicitly change a string object when needed. You can only free the reference and attempt to force a garbage collection.

For a book on the issue - http://www.amazon.com/exec/obidos/tg...books&n=507846


Catch me in unerror irc later if you'd like to go over this some more.

Thanks for clearing up the definitions of private, public, protected for me.

VicC > It sounded like you had the right things in mind but it came out discombobulated. Happens to me all the time.

I've just started a java programming course and they do push the fact that it's alot more secure than many other common languages.

Well, that all depends on the features you use and how you use them. It is arguable that some of the .net security measures are better than what is currently implemented in java... It's a fairly complex and broad topic.

Quote:

---

A protected variable can only be read but not changed

---

Quote:

---

Public is open to anyone, protected is open to members of the same package, and private is only accessible from the same class.

---

Both of you have your conceptions of protected mixed up. Java in fact defines 4 and not 3 access specifiers, public, protected, private and default or package private. Public members are open to all objects, private members to only the object itself (or "this" in java) and protected members to this and objects of derived classes. The default access specifier is package private, which means that it's open to access by classes in the same package.

Sorry in advance for the length of the code.

Code:

---

package p;

class c
{
public int i;
protected int j;
private int k;
int l; //this is package private

c()
{
//if no object name is given before the variable, this. is assumed
i=2; //works
j=2; //works
k=2; //works
l=2; //works
}
}

class d extends c //d inherits i,j and l from class c
{
d()
{
i=2; //works
j=2; //works
k=2;//violates encapsulation and therefore generates a compile time error
l=2; //works
}
}

class e
{
c c1;  //object of class c
d d1; //object of class d
e()
{
c1=new c();
d1=new d();

e()
{
c1.i=0; //works
c1.j=1; //violates encapsulation and therefore generates a compile time error
c1.k=0; //violates encapsulation and therefore generates a compile time error
c1.l=4; //works

d1.i=0; //works
d1.j=0; //violates encapsulation and therefore generates a compile time error
d1.k=0;//member k was private in class c and therefore not inherited by d, generates a compile time error
d1.l=2;//works
}
}

---

In another package if we were to try to change l, the compiler would generate an error as it is package private.

This fourth access specifier (package private) is an addition to java from C++.
Cheers,
cgkanchi

Just didn't write about it in my post. That's why I included a link there for him to read up about it.