CSCI 611\ Lab 4
Lab Deliverable Files
I identified a Syntax error: Parse Error when I executed the code:
Lab Assessment Questions & Answers
1. What kind(s) of memory-management issues might arise in the program you reviewed?
- Stack overflow
- Memory leak
2. Provide at least one place in the code where integer error overflow issues should be
considered. In other words, where in the code should you think about possible overflows?
Explain whether or not this overflow issue could cause a problem.
Line 23. Instead of “ip” is should be ‘ip’. This may cause a stack overflow.
3. List all places where data enters the program you reviewed in this lab. Don’t forget to
document hidden inputs.
Channel.java; commands.java; DetectHttpPolling.java; Detection.java; Host.java;
PacketHandler.java; DNSQuery.java
4. Give an example of at least one direct object reference in the program you reviewed.
Explain how or when it could be a problem.
This is showing a DSN query. This can allow an attacker to get the IP address of the server, and
they can try an exploit it for any weaknesses. “Such flaws can compromise all the data that can be
referenced by the parameter. Unless the name space is sparse, it’s easy for an attacker to access all
available data of that type (OWASP, 2017.)”
Source: Top 10 2010-A4-Insecure Direct Object References. (n.d.). Retrieved October 28, 2017, from
https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References
5. What input validation is performed in the system you reviewed? Is it complete and correct?
HTML.
6. What exceptions can occur in the program you reviewed? Is exception handling complete
and correct?
IllegalArgumentException, there doesn’t seem to be any red showing an error on that line of
code. I would say it is correct.
Challenge Questions
1. Use the Internet to research the following security review tools, and find at least one other
similar tool.
o Agnitio at http://sourceforge.net/blog/agnitio/
o Google Code's code review tool at
https://code.google.com/p/support/wiki/CodeReviews
Veracode (https://www.veracode.com/security/code-review) is another tool that could help test
codes.
•
How well written is the code you reviewed? Is it written in a manner that would
make a good production-quality tool for a network administrator to use?
The code didn’t work, so I don’t think it is well written. I could be wrong. Only a couple of things
were highlighted in red, so I assume they are typos, and if they are fixed it could work.
•
Discuss how a security code review for an embedded system would be similar to and
different from a security code review of a Web application containing the same
number of lines of code.
All code should be reviewed and tested to identify errors and vulnerabilities. Any errors can cause
a glitch or malfunction in whatever product the code was for. One example of bad coding is the
Therac-25. One bad error code cause this medical device to overdose patients who were getting
treated for cancer. This is what makes an embedded system different from a web application.
Depending on what the code it used for, it can cause a lot of damage or even death if not checked
and verified.
Web applications can cause huge financial loss if it is not reviewed or can be exploited for other
malicious intent. Either platform the code needs to be reviewed and tested.
•
Discuss how a security code review for a system written in C would be similar to and
different from a security code review of a system written in Python or Ruby.
C, Python, and Ruby can all be subjected to cross-site scripting, injections, etc. if not properly
reviewed. With any platform of code, any loose ends can be exploited and cause a lot of problems
down the line if they are not tested and reviewed.
The difference between them all is the level of programing. Ruby is supposed to be less confusing
and easy to use.
Python is great for beginners and is supposed to really easy to learn and execute.
C++, from my experience, makes you want to scream in a pillow. C++ is a more high level of
programming.
Code Review Checklist
Requirement
Complaint
(Y/N)
Non-
Compliant
(Y/N)
Remarks/Comment
1.
Does the code meet the
project requirement?
2.
Was the requirement
specific and stated the
functionality needed?
3.
Are all the functions
documented?
4.
Is the code functioning
properly?
5.
If the code came from a
library, was it tested
before altered?
6.
Are errors corrected and
documented?
7.
Are all errors re-tested?
8.
Has the code been
validated?
9.
Is the code properly
signing/unsigning
conversions?
10.
Has the code been fully
tested for vulnerabilities?
11.
Have the vulnerabilities
been documented?
12.
Have the vulnerabilities
been mitigated?
13.
Has the code been re-
tested after vulnerability
mitigation?
14.
Are there duplicate lines
of code? Are they
necessary/unnecessary?
15.
Are there any loops
which may become
infinite?
16.
Has the whole process
been documented,
reviewed, and approved
for code release?
