The module for this lesson is still under development. Please contact us if you have any questions.


Best Practices for Secure Variables – CS1

Read Background
Execute Lab Assignment
Complete Security Checklist
Answer Discussion Questions




During the last few years, the number of vulnerabilities being discovered in applications is far greater than the number of vulnerabilities discovered in operating systems. There are all sorts of programming ideas and even template type code available to make computer programs more secure. The purpose of this lab is to have security begin at the design stage. It is much easier (& smarter) to create secure code from design than to try to secure it during coding.


The cost of fixing system vulnerabilities and the risk associated with vulnerabilities after system deployment are high for both developers and end users. Steps to reduce the cost of system maintenance and the risk of security vulnerabilities need to be adopted by software development organizations. While there are a number of best practices available to address the issue of software security vulnerabilities, these practices are frequently difficult to reuse due to the implementation specific nature of the best practices. In addition, greater understanding of the root causes of security flaws has led to a greater appreciation of the importance of taking security into account in all phases in the software development life cycle, not just in the implementation and deployment phases. Many current best security practices focus on implementation and deployment issues and so do not address security flaws introduced in earlier phases of the development process

Risk – How Can It Happen?

Application software that does not properly check the size of user input, fails to sanitize user input by filtering out unneeded but potentially malicious character sequences, or does not initialize and clear variables properly could be vulnerable to remote compromise. Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, and cross-site scripting code to gain control over vulnerable machines.

Example of Occurrence:

In one attack in 2008, more than 1 million web servers were exploited and turned 25 into infection engines for visitors to those sites using SQL injection. During that attack, trusted websites from state governments and other organizations compromised by attackers were used to infect hundreds of thousands of browsers that accessed those websites. Many more web and non-web application vulnerabilities are discovered on a regular basis.

Code responsibly – How Can I Avoid Application Attacks Via Variables?

  1. Declare your variables all on different lines.
    for example, we all know the following is acceptable (& easy)

    int a, b, c, d;


     int a;
     int b;
     int c;
     int d;

    is more secure.

  2. “Global” variables (those declared outside of any method, but inside of main) are easy to design and define, but they are “alive” during the entire program’s execution, making them susceptible to attack. Scope minimization also helps developers avoid common programming errors, improves code readability by connecting the declaration and actual use of a variable, and improves maintainability because unused variables are more easily detected and removed. Therefore, these types of variables should be avoided.
  3. Constants should be declared as static final and denoted with UPPERCASE CHARACTERS. The static modifier says that the constant is a class variable (the closet we come to a global variable in JAVA). The final modifier tells the program that this variable cannot be changed; therefore, malware cannot change it, making the variable more secure. These types of variables are usually declared private, as well.
  4. Reuse of identifier names in subscopes leads to obscuration or shadowing. The identifiers in the current scope render those defined elsewhere inaccessible; such ambiguity burdens code maintainers, especially when code requires access to both the original named entity and the inaccessible one. The problem is aggravated when the reused name is defined in a different package. A simple name may occur in contexts where it may potentially be interpreted as the name of a variable, a type, or a package. No identifier should obscure or shadow another identifier in a containing scope. For instance, a local variable should not reuse the name of a class field or method, or the class name or package name. Similarly, an inner class name should not reuse the name of an outer class or package.

Lab Assignment


Program 1

public class SecureVariablesLab
	int k, j;
	int result;
	private int count;
	static private final int MAX_COUNT;
	public void counter ()
		count = 0;
		while (condition ())
				/* … */
				if (count++ > MAX_COUNT) return;
/* no other method references count */
/* but several other methods reference MAX_COUNT */
	private void doLogic()
			int i=0;
			for (i=0; i<10; i++)
					/* … */
			for (int i=0; i<20; i++)
					/* … */

*Copying and pasting programs may result in syntax errors and other inconsistencies. It is recommended you type each program.

Security Checklist


Security Checklist

Vulnerability: Variables Course: CS1
Check each lines of code Completed
1. Underline any variable which may be vulnerable.
2. Mark with a V multiple variable declarations per line
3. Circle each constant.
4. Mark with a V any variable that is shadowed.
5. Mark with a V any variable whose scope is not minimised.
Highlighted areas indicate vulnerabilities!

Discussion Questions

  1. What is the most vulnerable area of an information system? Explain your answer using the information you read in the Background section.
  2. What happens when a class (“global”) variable is declared in terms of its time in RAM? Explain.
  3. What is the purpose of a constant variable?
  4. What is the rule for using inner class & outer class names that are the same?
Copyright © Towson University