Part5: https://www.youtube.com/watch?v=aLRSBZ3pfjw
Authentication
Authorization
Secure data HTTPs
Penetration testing
(twitter API)
Large file upload
Phishing
SQL Injection
Javascript Injection
Trojan Injection
Showing posts with label Security Testing. Show all posts
Showing posts with label Security Testing. Show all posts
Thursday, December 19, 2013
Sunday, December 01, 2013
Security Testing
Since
PCs and the Internet came on the scene in the 1980s, security threats
have gradually increased, with the biggest increase coming when hackers
turned their attention to the clients. They tried to steal usernames and
passwords to gain access to servers using techniques such as installing
keystroke grabbers. They also used phishing and pharming to get users
to voluntarily turn over password information.
The number of vulnerabilities has increased dramatically since attackers turned their attention from networks and servers to clients. Across all systems and operating systems, at least 6,000 new, exploitable vulnerabilities are found each year (CERT 2006). This trend is expected to continue.
To prevent vulnerabilities, we do need to factor security into our software lifecycle, but we must also learn the mental models hackers use to attack systems.
Another factor in preventing security vulnerabilities is to use standards. Two evaluation standards are Orange Book and Common Criteria. These types of standards help us define our goals for security. They help us think about who's attacking, what we need to protect, and so on.
Security engineering helps us develop software securely across the product development lifecycle, from requirements through maintenance and operation. It is a process for making sure our security goals and requirements are met. We can think of it as the software development lifecycle with a security aspect on top of it.
Industry-wide, security must become more robust. When computers first came into use, few people envisioned a world in which every home had a computer and in which any two computers could share information. Therefore, security was not built into the underlying architecture. Username and password were created as an accounting system, providing a way to log how much time each user spent on the system, not for security. But username and password have become the industry's de facto security system and continue to be used this way even though hackers have proven that they can circumvent that system. Security technology must move beyond the password.
Build security into the development cycle. At every part of the software development lifecycle, from requirements to maintenance, you need to consider security. Think about the parts of your system that are vulnerable and make sure your specifications include plans to make them secure. Understand who your attackers are. Ad hoc fixes are expensive and less effective than doing it right from the beginning.
Standards for securityUsing standards is one way to build security into the development cycle. Two standards that we'll discuss are Orange Book and Common Criteria.
Common Criteria is the commercial worldwide standard for evaluating security. Orange Book was USA only, administered for the Department of Defense.
The application was vulnerable to a resource exhaustion attack.
The number of vulnerabilities has increased dramatically since attackers turned their attention from networks and servers to clients. Across all systems and operating systems, at least 6,000 new, exploitable vulnerabilities are found each year (CERT 2006). This trend is expected to continue.
To prevent vulnerabilities, we do need to factor security into our software lifecycle, but we must also learn the mental models hackers use to attack systems.
Another factor in preventing security vulnerabilities is to use standards. Two evaluation standards are Orange Book and Common Criteria. These types of standards help us define our goals for security. They help us think about who's attacking, what we need to protect, and so on.
Security engineering helps us develop software securely across the product development lifecycle, from requirements through maintenance and operation. It is a process for making sure our security goals and requirements are met. We can think of it as the software development lifecycle with a security aspect on top of it.
- Infection with spambots, which send spam from the infected PC
- Botnets, which put a number of computers under control of the attacker, making them capable of a coordinated attack ranging from spamming for phishing and pharming attacks to distributed denial of service (DoS) attacks
- E-mail attachments that contain malicious data such as worms and trojans
- Phishing e-mails, which simply ask users to give their information to what they think is a legitimate site
- Pharming, which, through techniques such as Domain Name System poisoning, redirects a website's traffic to a false website
- Downloads from the Internet that contain spyware, adware, or other malicious content
- Taking advantage of the copy-protection scheme used by music CDs that installs a rootkit (giving root access) on the user's computer
Testing for security is an emerging field, but tools are available and you can test your code for common vulnerabilities.
Security
is in some ways a moving target, but learning about and adopting good
practices will increase your software's security. The following are two
actions that can improve security.
Industry-wide, security must become more robust. When computers first came into use, few people envisioned a world in which every home had a computer and in which any two computers could share information. Therefore, security was not built into the underlying architecture. Username and password were created as an accounting system, providing a way to log how much time each user spent on the system, not for security. But username and password have become the industry's de facto security system and continue to be used this way even though hackers have proven that they can circumvent that system. Security technology must move beyond the password.
Build security into the development cycle. At every part of the software development lifecycle, from requirements to maintenance, you need to consider security. Think about the parts of your system that are vulnerable and make sure your specifications include plans to make them secure. Understand who your attackers are. Ad hoc fixes are expensive and less effective than doing it right from the beginning.
Standards for securityUsing standards is one way to build security into the development cycle. Two standards that we'll discuss are Orange Book and Common Criteria.
Common Criteria is the commercial worldwide standard for evaluating security. Orange Book was USA only, administered for the Department of Defense.
- Security engineering is a process and a needed part of the software development lifecycle.
- Security attacks have moved from password sniffing on the network to attacks on servers, and then to attacks on clients. Phishing and pharming attacks are increasing and becoming more successful.
- When the schedule does not include security testing, vulnerabilities are likely. Also, it is important to understand the capabilities and the limits of the security features you are using. Use standards to make sure your security goals are met.
- Orange Book was the USA-only standard for security. Common Criteria is newer and is more flexible than Orange Book.
Buffer Over Flow/Buffer Over Run
SSL : SSL
only makes data confidential and gives it integrity. It doesn't say
what’s in the content. If the content was malicious, all that SSL did
was give a very confidential path for malicious content.
The hackers could read the authentication file.
The default admin password hadn't been changed.
A privileged program (setuid) was vulnerable and allowed a local root exploit.
There are three types of attacks. In all of these attacks, the hacker is exploiting a security bug.
Malicious data, in which the attacker injects data that causes the system to fail.
Example: Parsing errors occur when illegal and potentially damaging data makes it past parsing.
An example of a parsing error is one that has been fixed repeatedly in IIS, Microsoft's web server. Hackers have used variations of the same attack over several years, repeatedly finding ways around the fixes. The attack is called the directory traversal attack. Hackers try to traverse and climb up directories in the operating system on the server by putting ../ in the URL. The goal is to open restricted files such as password files.
Network attacks, in which the attacker tries to steal or manipulate information as it passes across the network. Examples include password sniffing, man-in-middle attacks, replay, and distributed denial of service.
Side-effect attacks, in which the result of a normal operation gives attackers information they can use to gain access to the system. Examples include error messages and timing of cryptographic operations.
Side-channel attacks occur when attackers use a side-effect of a process to learn more about the system they want to attack.
Examples include:
There are three types of attacks. In all of these attacks, the hacker is exploiting a security bug.
Malicious data, in which the attacker injects data that causes the system to fail.
Example: Parsing errors occur when illegal and potentially damaging data makes it past parsing.
An example of a parsing error is one that has been fixed repeatedly in IIS, Microsoft's web server. Hackers have used variations of the same attack over several years, repeatedly finding ways around the fixes. The attack is called the directory traversal attack. Hackers try to traverse and climb up directories in the operating system on the server by putting ../ in the URL. The goal is to open restricted files such as password files.
Network attacks, in which the attacker tries to steal or manipulate information as it passes across the network. Examples include password sniffing, man-in-middle attacks, replay, and distributed denial of service.
Side-effect attacks, in which the result of a normal operation gives attackers information they can use to gain access to the system. Examples include error messages and timing of cryptographic operations.
Side-channel attacks occur when attackers use a side-effect of a process to learn more about the system they want to attack.
Examples include:
- Timing attacks, in which the attacker learns from the amount of time a process takes
- Returned error codes
- Power analysis
- RF analysis
