Consider the following scenarios. Find a total of four vulnerabilities in the fo
ID: 3885936 • Letter: C
Question
Consider the following scenarios. Find a total of four vulnerabilities in the following scenarios, and, for each vulnerability, indicate which security goal (confidentiality, integrity, or availability) is threatened, with a one sentence justification of how. Propose an approach that mitigates the vulnerability that you describe. Note that you should find at least one vulnerability per scenario.
A PHP program stores a user's login name and password in a cookie on the user's machine for a limited amount of time. In order to prevent an unauthorized individual from recovering these credentials, the cookie is encrypted using the DES algorithm with a 56-bit key that is securely stored on the server.
Bob has written an implementation of AES-256/ECB which he plans to use to encrypt the contents of back up tapes that are sent to an offsite storage facility.
Alice is taking a different approach. She has designed her own symmetric key encryption program, and she would like to use this instead of Bob’s. She believes that this approach will lead to a more secure approach since both the key and the encryption algorithm will be secret.
Explanation / Answer
All web sites which deals with sensitive personal information of users it requires them to authenticate themselves with valid usernames and passwords. If the login credentials contain long digit or a complex passwords that users often find it difficult to remember the credentials an hence store it in local machine i.e the cookies of local machine. Thus they turn to the browser to help them remember login credentials which can be threat.
vulnerabilities of storing a user's login name and password in a cookie on the user's machine are:
* Cookie Poisoning
Cookies are supposed to be sent back to the server unchanged, but attackers can modify the value of a cookie before sending them back to the server. This is typically done to carry out some sort of attack against the server that relates to some sort of data contained in the cookie. Like, if a cookie contains the price per item for something in the shopping basket, a change to this value in the cookie may cause the server to charge the user a lower price for that item. This process of modifying a cookie before it is sent back to the server is called cookie poisoning. Sometimes, cookie poisoning is used after cookie theft.
So here integrity and confidentiality are threatened.
Most Web sites only store a randomly generated unique session identifier in the cookie, and everything else is stored on the server. This pretty much eliminates the threat of cookie poisoning.
* Cookie Inaccuracies
Even beyond deliberate cookie tampering, there are aspects of how cookies are used in some situations that cause cookies to carry inaccurate data on which we base sensitive transactions.
One issue is that separate people using the same computer, browser, and user account will unavoidably share cookies. Another is that if a single user uses multiple browsers, multiple computers, or multiple user accounts, it means that the user will have multiple sets of cookies.
So here integrity and availability are threatened.
* Cross-Site Cooking
Despite the fact that every site is supposed to have its own set of cookies and to not be able to alter or set cookies for any other site, there are some browser flaws that cause cross-site cooking vulnerabilities and allow malicious sites to break this rule.
This is similar to cookie poisoning, but instead of the attacker attacking the site itself, the attacker is now attacking non-malicious users with vulnerable browsers. Many browsers have a flaw in how they deal with overly relaxed cookie domains. So, the actual intent is that if you wish to set a cookie on a .com site, you need to specify ".mysite.com" as the two-dot name. In some browsers, it's possible for a cookie to set for the entire .com.au (for example) domain.
So here integrity and confidentiality are threatened.
* Insecure Direct Object References
It occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key as in URL or as a FORM parameter. The attacker can use this information to access other objects and can create a future attack to access the unauthorized data. Using this vulnerability, an attacker can gain access to unauthorized internal objects, can modify data or compromise the application.
Examples:Changing "userid" in the following URL can make an attacker to view other user's information.
http://www.vulnerablesite.com/userid=123 Modified to http://www.vulnerablesite.com/userid=124
An attacker can view others information by changing user id value.
So here integrity is threatened.
So to prevent this one must implement access control checks, Avoid exposing object references in URLs and Verify authorization to all reference objects.
vulnerabilities for AES-256/ECB to encrypt the contents of back up tapes that are sent to an offsite storage facility:
Backup encryption is one of many activities that formulate a comprehensive security strategy. In many environments, storage has operated outside of the realm of security officers for some time, as their main focus has been primarily on areas such as perimeter security, intrusion detection/prevention and protection of host systems. As a result, the storage infrastructure – both primary storage and especially copies of primary storage – is likely to be an Achilles’ heel when it comes to security. Policies for data security are a corporate concern and should be a fundamental element of an enterprise security strategy.
So here integrity is threatened.
It is important to test the process. As a company grows, information and data protection needs change, so the information security practices must change as well. Once the end-to-end plan has been developed, defined and communicated to the appropriate people, it is time to begin execution. Ensure that the tools, technologies and methodologies are in place that need to be deployed.
vulnerabilities for symmetric key encryption:
A cryptographic system can only be as strong as the encryption algorithms, digital signature algorithms,
one-way hash functions, and message authentication codes it relies on. In other words, break any of them,
and you’ve broken the system. Encryption algorithms
do not necessarily provide data integrity. Secret-key cryptography, also known as symmetric-key cryptography, employs identical private keys for users, while they also hold unique public keys. “Symmetrickey”
refers to the identical private keys shared by users. Users employ public keys for
the encryption of data, while the private keys serve a necessary purpose in the decryption
of data. Key exchange protocols do not necessarily ensure that both
parties receive the same key. Some not all systems that use related cryptographic
keys can be broken, even though each individualkey is secured.
The biggest obstacle in successfully deploying a symmetric-key algorithm is the
necessity for a proper exchange of private keys. This transaction must be completed in a
secure manner.
However private keys used in symmetric-key cryptography are robustly resistant to
brute force attacks. While only the one-time pad, which combines plaintext with a
random key, holds secure in the face of any attacker regardless of time and computing
power, symmetric-key algorithms are generally more difficult to crack than their publickey
counterparts.