There are several things that you can do to prevent problems. I would recommend putting the DNS servers behind your current firewall and give them a public IP address. When allowing port 53 through the firewall, be sure to allow both TCP and UDP through. I learned this one the hard way the first time I put DNS servers behind a firewall. There were intermittent problems in DNS resolution until both TCP and UDP were allowed through the firewall for port 53. If you put the DNS servers behind your current firewall, I would suggest putting the servers in a different subnet from your server farm or anything else on your network. I would also suggest putting an access control list statement in the switch for the subnet that the DNS servers will be on that doesnt allow traffic from the DNS servers to ingress onto your network and only talk over your Internet connection. Another option is to put the servers on a DMZ connection. Some firewalls allow this with the installation of an additional network card if the firewall you have doesnt have an additional port already available.
Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user. Site tasks are usually linked to specific urls (Example: http://site/stocks?buy=100&stock=ebay) allowing specific actions to be performed when requested. If a user is logged into the site and an attacker tricks their browser into making a request to one of these task urls, then the task is performed and logged as the logged in user. Typically an attacker will embed malicious HTML or JavaScript code into an email or website to request a specific 'task url' which executes without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw. Injection via light markup languages such as BBCode is also entirely possible. These sorts of attacks are fairly difficult to detect potentially leaving a user debating with the website/company as to whether or not the stocks bought the day before was initiated by the user after the price plummeted.
This paper addresses digital forensic analysis tools and their use in a legal setting. To enter scientific evidence into a States court, a tool must be reliable and relevant. The reliability of evidence is tested by applying “Daubert” guidelines. To date, there have been few legal challenges to digital evidence, but as the field matures this will likely change. This paper examines the Daubert guidelines and shows that open source tools may more clearly and comprehensively meet the guidelines than closed source tools.
This guide describes how you can automatically scan files uploaded by users through a web form on your server using PHP and ClamAV. That way you can make sure that your upload form will not be abused to distribute malware. To glue PHP and ClamAV, we install the package php5-clamavlib/php4-clamavlib which is rather undocumented at this time. That package is available for Debian Etch and Sid and also for Ubuntu Dapper Drake and Edgy Eft, so make sure you use one of these platforms. I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!
PHP has become the most popular application language on the web, but common security mistakes by developers are giving PHP a bad name. Here's how PHP coding errors have become the new low-hanging fruit for attackers, contributing to the phishing problems on the web. PHP became one of my favorite languages because of how quickly one can write a highly functional, standards-based web application with a database back-end. Unfortunately, attackers are taking these applications down even faster than they appear.
Undoubtedly you have all seen photographs of people on TV and online who have been blurred to hide faces. For the most part this is all fine with peoples' faces as there isn't a convenient way to reverse the blur back into a photo so detailed that you can recognise the photo. So that's good if that is what you intended. However, many people also resort to blurring sensitive numbers and text. I'll illustrate why that is a BAD idea.
The ability of modern browsers to use
asynchronous requests introduces a new type of attack
vectors. In particular, an attacker can inject client side
code to totally subvert the communication flow between
client and server. In fact, advanced features of Ajax
framework build up a new transparent layer not controlled
by the user. This paper will focus on security aspects of
Ajax technology and on their influence upon privacy
issues. Ajax is not only a group of features for web
developers: it's a new paradigm that allows leveraging the
most refined client side attacks.
When you use a system often, you tend to fall into set usage patterns. Sometimes, you do not start the habit of doing things in the best possible way. Sometimes, you even pick up bad practices that lead to clutter and clumsiness. One of the best ways to correct such inadequacies is to conscientiously pick up good habits that counteract them. This article suggests 10 UNIX command-line habits worth picking up -- good habits that help you break many common usage foibles and make you more productive at the command line in the process. Each habit is described in more detail following the list of good habits.
Within one week's time, we stumbled across two different sites using cookies the wrong way. While the attack vectors were a bit different, both sites trusted the cookie data to secure their users’ accounts. Therefore, this week we are going to spend some time discussing cookies, when they should be used, and what can happen if they are misused. Before a web developer can understand the dangers associated with trusting cookies to store sensitive data, it is important to recognize what they are, and what they aren't. Specifically, a cookie is just a small text file that is stored on your computer by a specific website. Cookies are not programs, they can't read your personal data, and they don't cause spam. In fact, cookies can be very helpful if used within the correct context.
Websites are as vulnerable as ever, according to a survey of Web application security professionals who test sites for security holes. The survey, conducted by researcher Jeremiah Grossman on his blogsite, polled more than 60 security pros, 63 percent who work for vendors or consultants, 23 percent for enterprises, 5 percent for government, and 10 percent for other types of organizations. These are the guys in the trenches who hammer on Websites regularly -- 53 percent said all or almost all of their job is dedicated to Web app security (versus development, general security, and incident response); 28 percent said about half; and 20 percent said "some."
