Web Server Application Attacks

April 15, 2015

Strayer University
Spring 2015

Web Server Application Attacks

Increasingly the world is becoming more and more dependent upon technology. With this dependency comes responsibility. In order to assure a company’s success, web security is a key element and has to be taken seriously; it should be at the top of the list when it comes to a company’s priorities. It is better for a company to employ an IT security policy that is more proactive than reactive. Hackers and attackers are constantly developing ways to penetrate infrastructures and there are several web server application vulnerabilities that companies should become familiar with. This document will discuss three common vulnerabilities and attacks; broken authentication, security misconfiguration, and sensitive date exposure. Mitigation strategies will also be discussed.
Broken authentication involves the threat of an attacker stealing critical information such as passwords or other account information. The attacker is then able to pose as the compromised user, acting as if they are them. In most cases, the attacker targets privileged accounts. The impact to the company is as great at the value of the information that was stolen.
According to an article on the website Liquid Web “protecting your application from session ID exploits requires a strong set of authentication and session management controls, secure communication and credential storage. In addition, services like Brute Force Detection (BFD) watch your log files for failed login attempts and will blog IP addresses that have several in a short period of time.”
The picture below shows a simple design of an infrastructure set up to protect web servers from attackers with the use of firewalls adding additional layers of protection making it more difficult for to access the operational server. Figure 1: Diagram of DOS Architecture

Kalman identifies a few pitfalls that can attribute to broken authentication;
1. The URL might contain the session id and leak it in the referer header to someone else.
2. The passwords might not be encrypted either in storage or transit.
3. The session ids might be predictable, thus gaining access is trivial.
4. Session fixation might be possible.” (Kalman, 2015)
Security Misconfiguration
System administrators can create scripts similar to those that attackers are using to exploit their own systems to identify vulnerabilities. Once that is completed you are able to install the necessary patches to protect against it. “The good news is that it’s typically as easy to detect this type of vulnerability as it is to exploit.” (Hamit, 2014)
Steps for prevention are “Have a good (preferably automated) “build and deploy” process, which can run tests on deploy. The poor man’s security misconfiguration solution is post-commit hooks, to prevent the code from going out with default passwords and/or development stuff built in. (Kalman, 2015).
Sensitive Data Exposure “This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. And while it goes without saying that session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important and cannot be over-emphasized.” (Hamit, 2014)
In order to prevent sensitive data exposure during the transfer of information, a secured protocol such as HTTPS should be used in conjunction with proper certificates. This presents an added layer of security that would not be present with the use of an HTTP. A good rule of thumb to consider when protecting data that has been stored is to purge sensitive data on a regular basis. I cannot be stolen if it has been properly deleted. The data that you need to keep should be stored, encrypted, and the passwords should be hashed. It is also important to remember to treat backups with the same level of security and precaution.
“DNSSEC is meant to prevent DNS based exploits and redirections like DNS cache poisoning attacks by allowing domain names and corresponding IP addresses to be verified using digital signatures and public-key encryption.” DNS Security Extensions (DNSSEC) assists in the protection against the vulnerabilities that were previously discussed within this document. In Federal agencies were required to support DNSSEC on their Web sites under an Office of Management and Budget mandate issued in August 2008. The deadline for compliance was Dec. 31, 2009. (Marsan, 2012) In Marsan’s article, she mentions that although the government was required to implement DNSSEC over two years ago, there are still agencies who have yet to comply. She goes on further to quote subject matter experts who explained why they believe agencies have not been compliant. One CKO of a federal IT research market firm recalls hearing about DNSSEC but was not under the impression that it was high on the list of priorities. Others have mentioned that they believe government agencies could feel that they have enough security measures in place and will not benefit from the implementation of DNSSEC.
There are documented attacks that could have been prevented with DNSSEC. “DNSSEC solves what's called the Kaminsky vulnerability, a fundamental flaw in the DNS that was disclosed in 2008. This flaw makes it possible for hackers to launch cache poisoning attacks, where traffic is redirected from a legitimate Web site to a fake one without the Web site operator or end user knowing.” (Marsan, 2012).
Based on my research it is unclear as to why some government agencies have remained non-compliant. As the security manager at a government agency, I would identify what countermeasures were in place. To remain compliant and cost-effective, I would identify redundancies in the security posture and allow DNSSEC to be the prevailing security mechanism. One complaint that was discovered during my research was its affects to availability in that it delays the server’s response to the user’s request. The delays that have been mentioned however, are not significant enough to ignore regulations with the sole purpose of security. Other problems that are more significant involve digital signatures. DNS does not have access to the signing keys so it prevents notification to the user that a record does not exist. As a part of the plan to mitigate the issues that arise experts suggest that you alphabetize subdomains and include what-if statements such that a response is generated that will appear digitally signed and will notify the user. References

Hamit, J. (2014, April 1). Top Ten Web Security Risks. Retrieved from Credera: https://blog.credera.com/technology-insights/open-source-technology-insights/top-ten-web-security-risks-security-misconfiguration-5/
InternetIdentity.com. (2010, September 22). Q3 State of DNS Report: DNSSEC Deployment in .gov. Retrieved from Internet Identity: internetidentity.com/.../gov_dnssec_deployment_report_201009.pdf
Kalman, G. (2015, April 13). 10 Most Common Web Security Vulnerabilities. Retrieved from Toptal: http://www.toptal.com/security/10-most-common-web-security-vulnerabilities
Liquid Web. (2014, November 13). Tag: Broken Authentication How To Protect Your Ecommerce Site From Holiday Hacks. Retrieved from Liquid Web: https://www.liquidweb.com/blog/index.php/tag/broken-authentication
Marson, C. (2012, March 15). 40% of U.S. government Web sites fail security test. Retrieved from Network World: http://www.networkworld.com/article/2186860/data-center/40--of-u-s--government-web-sites-fail-security-test.html