A collaboration from 3 SPSU students, enrolled in IT6753, on Web Application Security.
Monday, February 24, 2014
So you thought you were safe on a Mac? LOL
Apple SSL Vulnerability Affects OSX Too - ThreatPost
Being an avid Apple user, I have had to crush the dreams of several other Apple fans when it comes to the security of their beloved operating system. I switched from using a Windows based PC to an Apple full-time shortly after being subjected to Vista. Though I had never owned an Apple of my own until that point, my husband and several friends have always preferred their computers over mine, boasting about how secure they were and how vulnerable I was. No matter who would make the comment, I would let them know that they were never any more secure than I was, and in fact could be more vulnerable.
Mac's operating system was not built more secure than Window's OS, there is no magic code that Apple has implemented that has made their OS insusceptible or invisible to hackers. Less people used Macs. More importantly to hackers, less BIG business money makers used Macs. If a hacker was looking to threaten a massive audience, or to steal valuable information, then the amount of time they spent searching for a vulnerability and then implementing a strategy had better be a sure bet. And with most of the world running on the Window's OS, this is their market! At least it was...
And it was this lack of a customer base using Apple's OS that gave users the facade that they were "safer" than their PC counterparts.
Now, the story of the century! Oh my goodness, the impenetrable Apple OS has a security vulnerability! I can't believe Apple would do this to US, it's beloved users!
How shocked would we be if Windows announced a security vulnerability was discovered?
Don't even get me started on the updates and patches to Windows that go almost unnoticed...almost.
Oh, COME ON! Give me a BREAK! Just one day before, Google released an update for Chrome to fix several high-level vulnerabilities:
Google Fixes 28 Security Flaws In Chrome 33 - ThreatPost
So a high-level security vulnerability has been discovered in Apple's OS, and we know this NOT because of any malicious attack or attempt, but because Apple has released an update to iOS to fix this issue and is creating a fix for OSX. And to that affect, I say thanks to Apple for releasing an update before a hacker discovered the vulnerability!
Thursday, February 20, 2014
NTP Reflected DDoS
Definition of common terms used
throughout the article are always the best place to start. The two most important definitions to be able
to understand this article in its entirety are that of NTP and DDoS. NTP (Network Time Protocol) is a networking
protocol that is shared among computer systems and data networks that provides
time information synchronization among them.
The next definition, DDoS (Distributed Denial of Service) is a type of
computer system and network exploitation “attack” where a malicious party
attempts to flood a computer or network’s bandwidth in an attempt to render it
unable to communicate. The following
article will be an attempt to educate and inform the readers of a rapidly
growing and popular method of malicious attacks that can easily go un-noticed
by the often times unaware offending party.
THREAT
The recent rate at
which these attacks are becoming more commonplace is alarming. I have personal experience with these types
of attacks and the needed steps to mitigate these types of threats. The attack starts by a malicious party or
parties deciding upon the target they would like to “attack”. Once the target has been identified and their
IP address obtained, the attacker(s) generate very large amounts of small
8-byte UDP “monlist query” packets that are sent to vulnerable or open NTP
servers. When these requests are sent to
the NTP servers they are sent as spoofed sessions with a return IP address of
the “target” the attacker(s) are intending to take down. When the NTP server receives these requests
it replies to each of the 8-byte “requests” with 400-byte “replies”. As can be deduced from this math, as the
number of 8-byte requests grows, so does the 400-byte replies by a 50:1
ratio. The attacker(s) could for
instance send 1 GB of traffic and the NTP servers return 50 GB of replies.
SOLUTIONS
The NTP protocol
uses UDP (User Datagram Protocol) port 123 as its destination port. From the research that I have done the
recommended plan to limit the impact and vulnerabilities of this type of attack
is to update all NTP servers to a version of NTP which removes the “monlist”
command, typically version 4.2.7 or later.
However, often times upgrading code is not an option immediately and the
simplest solution is to block all traffic to a destination host with a UDP
destination port of 123 for any source traffic.
For those hosts that NTP cannot be completely disabled for, there are
other methods of limiting the traffic to specific trusted hosts that need NTP
using Access Control Lists and authentication methods. Also, there are restrictions that can be
placed in the NTP server configuration file that will stop it from replying to
NTP queries.
References:
Sunday, February 16, 2014
Defining Web Application Security
As web applications are becoming increasingly more complex and dynamic, so are the
malicious actions taken on them. The security of a web application or service is vital to maintain
proper function of the application, protect the users of the application, and protect the data
transferred through or stored by the web application. Every application has vulnerabilities, and
being able to detect them and protect against threats is the first step in protecting information
through web application security.
In an effort to raise awareness of threats to software, and to enhance the security of
applications, the Open Web Application Security Project (OWASP) started the OWASP Top Ten
Project that “represents a broad consensus about what the most critical web application security
flaws are”. This project details the most common risks to applications, educating others on how
to identify security vulnerabilities and steps to prevent, or mitigate, threats to web applications
and software. As of 2013, OWASP has identified the following as the top 10 web application
security risks:
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
This list does not include all of the risks to web applications, and not all of these risks pertain to
individual applications.
The purpose of this blog is to provide knowledge and understanding of the web application
security standards today. Follow us as we answer the questions relevant to securing
information on the world wide web:
• What is a threat?
• How do you detect breaks in the security of a web application/service?
• What steps can be take to protect information?
Knowing the web application, and knowing the users, will help identify relevant risks. The most
powerful tool in securing an application is to continuously improve the security.
malicious actions taken on them. The security of a web application or service is vital to maintain
proper function of the application, protect the users of the application, and protect the data
transferred through or stored by the web application. Every application has vulnerabilities, and
being able to detect them and protect against threats is the first step in protecting information
through web application security.
In an effort to raise awareness of threats to software, and to enhance the security of
applications, the Open Web Application Security Project (OWASP) started the OWASP Top Ten
Project that “represents a broad consensus about what the most critical web application security
flaws are”. This project details the most common risks to applications, educating others on how
to identify security vulnerabilities and steps to prevent, or mitigate, threats to web applications
and software. As of 2013, OWASP has identified the following as the top 10 web application
security risks:
1. Injection
2. Broken Authentication and Session Management
3. Cross-Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross-Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
This list does not include all of the risks to web applications, and not all of these risks pertain to
individual applications.
The purpose of this blog is to provide knowledge and understanding of the web application
security standards today. Follow us as we answer the questions relevant to securing
information on the world wide web:
• What is a threat?
• How do you detect breaks in the security of a web application/service?
• What steps can be take to protect information?
Knowing the web application, and knowing the users, will help identify relevant risks. The most
powerful tool in securing an application is to continuously improve the security.
Labels:
Cross-Site,
Injection,
OWASP,
protect,
risk,
security,
software,
threats,
web application
Friday, February 7, 2014
NBC: All Visitors to Sochi Olympics Immediately Hacked
What can we do to secure our wireless devices and our data from hackers?
In an increasingly digitally wireless, always connected world, it is almost certain that you will have a mobile device connected to a network that you have no control over.
From Starbucks to universities, grocery stores, shopping malls, book stores, hotels, conference centers...networks are everywhere and ready for you to connect.
What data is on that device? Personal information, family member's addresses, your children's pictures and birth dates, their school information, banking information, calendars and schedules...
All this information could be used to impersonate you, track you, know when you will be at work or soccer practice, and how often you download music from iTunes and pay your mortgage, or when your paycheck is deposited.
Subscribe to:
Comments (Atom)
Wikipedia
Search results

