COSC 236
Lab 7
The goal of this lab is to get used with basic Java notions introduced so far and more looping structures (discussed in Lecture #6 and Lecture #7). Take a look at the examples and the sample programs in the lecture notes and try to apply the same concepts and style when writing your own programs. You will write 3 programs, given below.
1. Write a Java program that
will read numbers between 1 and 14 and will output the appropriate symbol for a
playing card of that rank (use switch). For cards
between 2 and 10 just print the rank, for 1 and 11 print "Ace", for
12 print "Jack", for 13 print "Queen", and for 14 print
"King". Use a for
loop to read and process n cards (input
from user). Your program should also handle invalid input.
Sample output:
Playing cards
program.
Give me some numbers
and
I will tell you the
appropriate playing card.
=============================================
How many numbers? -20
ERROR! Should be
positive. Reenter: 5
Enter card number: 23
ERROR! Out of range
(1-14). Reenter: 11
You have an Ace.
Enter card number: 14
You have a King.
Enter card number: 2
You have a two.
Enter card number: 13
You have a Queen.
Enter card number: 1
You have an Ace.
2. Use nested for loops
statements to draw triangles of "*"s. The number of "*"s on the last row is input
from the user (valid range: 5 to 21).
Sample output:
Drawing triangles
program.
==========================
How many triangles? 2
How many stars/last
row (5-21)? 25
Out of range. Reenter:
7
*
**
***
****
*****
******
*******
How many stars/last row (5-21)? 5
*
**
***
****
*****
3. Use nested for loops
statements to draw hallow boxes of "*"s. The boxes have the
same number of rows and columns and this number should be input from the user
(valid range: 5 to 21).
Sample output:
Drawing hallow
boxes program.
=============================
Do you want to
start(Y/N)? Y
How many rows/columns
(5-21)? 25
Out of range. Reenter:
7
*******
* *
* *
* *
* *
* *
*******
Do you want to
continue(Y/N)? Y
How many rows/columns
(5-21)? 5
*****
* *
* *
* *
*****
Do you want to
continue(Y/N)? N
Input Validation:
All Input is Evil
Background
Summary: Any input that comes into a program
from an external source (such as a user typing at a keyboard or a network
connection) can potentially be the source of security concerns and potentially
disastrous bugs. All input should be treated as potentially dangerous
Description: All interesting software
packages rely upon external input. Although information typed at a computer
might be the most familiar, networks and external devices can also send data to
a program. Generally, this data will be of a specific type: for example,
a user interface that requests the name of a person might be written to expect
a series of alphabetic characters. If the correct type and form of data
is provided, the program might work fine. However, if programs are not
carefully written, attackers can construct inputs that can cause malicious code
to be executed.
Risk:
How can it happen? Any data that can enter your program from an external
source can be a potential source of problems. If external data is not checked
to verify that it has the right type of information, the right amount of
information, and the right structure of information, it can cause
problems. Input that is not properly validated can impact any type of
computer program, from word processors to web servers and relational databases.
Example of Occurrence:
The Risks digest (http://catless.ncl.ac.uk/Risks
, an invaluable resource on computing systems gone wrong) carried a report of an
electronic commerce web site that failed to verify the quantity of items
ordered. After accidentally typing 1.1 for the desired quantity of an
item (instead of one), an amused customer found that the system would let him
order 1.1 cocktail shakers at $9.99 each, for a total of $10.99. A simple
check to verify that the quantity was an integer value would have eliminated
the absurd possibility of ordering one-tenth of a cocktail shaker. Source: Richard
Kaszeta, “Lack of sanity checking in Web shopping cart
software”, Risks Digest, 23(51) http://catless.ncl.ac.uk/Risks/23.51.html#subj11
How can I avoid
input validation problems?
Check your input: The basic rule is for input validation
is to check that input data matches all of the constraints that it must meet to
be used correctly in the given circumstance. In many cases, this can be very
difficult: confirming that a set of digits is, in fact, a telephone number may
require consideration of the many differing phone number formats used by
countries around the world. Some of the checks that you might want to use
include: data type, range of values, length of input, and format. If you ask
for a date and someone gives you a twelve digit number, it's probably wrong.
Some programming languages have tools that provide general input validation
support or specific support for handling common input formats. These facilities
should be used whenever possible.
Recover Appropriately: A robust program will respond to
invalid input in a manner that is appropriate, correct, and secure. When
your program runs across invalid input, it should recover as much as possible,
and then repeat the request, or otherwise continue on. Arbitrary decisions such
as truncating or otherwise reformatting data to make it fit should be avoided.
Problem: This program asks the user to type an
integer number. It will then print all of the even numbers that are greater
than or equal to zero and less than the number typed:
import java.util.Scanner;
public class InputValidationExample_Bad {
public
static void main(String[] args) {
Scanner input = new Scanner(System.in);
System.out.print("Please type a positive
integer: ");
int x = input.nextInt();
int i = 0;
while(i != x) {
System.out.println(i);
i += 2;
}
}
}
Questions:
1. Complete the following
checklist for this program.
2. Identify the potential input validation problems/errors.
3. Provide example inputs that might cause validation problems and describe the
problems that they might cause.
Security
Checklist (Vulnerability: Input Validation)
|
Task - Check
each line of code |
Completed |
|
1. Mark each variable declaration with a V |
_ |
|
2.Mark with all external inputs to these variables with a
V |
_ |
|
3.Identify
all uses of these variables that might lead to problems if the input is not
validated. Mark them with a V. |
_ |
Notes:
A. The lab will NOT be graded, do NOT hand anything in to the instructor.
B. The lab should be completed by the start of the next scheduled lab
class. Save the .java files on your disk and e-mail them
(attachments) to Vishal Patel at vpatel12@students.towson.edu
Very important: Make sure that you have COSC 236.section, your name,
and Lab#7 in the Subject box of your e-mail.
C. In case you have any problems, contact the TA or the instructor for
assistance.