Given the increased shift from packaged software to cloud computing, a growing number of applications are web-based. Both the business models of software-as-a-service, as well as the real-time distribution modelmake Web Apps the ideal platform for new projects. While web distribution has a number of upsides, in order to effectively scale applications,it’s crucial to implement best practices to safeguard data. Any database or code that remains in a cloud is potentially vulnerable to attack. We consulted with leading web application security specialists for their top security tips:

• Understand the Potential Sources of Vulnerability
Many developers assume that all attacks will come from outside of a network firewall, but this leaves open a potential attack from inside. Make sure that all data is guarded from unauthorized access by several layers of security,ensuring that lower-level employees, and others who might work in the office,do not have access to valuable code data. Internal attacks can come in any forms, all of which can be avoided by working to secure all levels of the application.

• Utilize Multiple Layers of Security for Your Application.
Often times, IT professionals will rely solely upon an external firewall in order to protect a web application. In order to truly get a high level of security,however, one must cover all the bases. In practice, this means having an effective network virus scanner that operates in real time as well as a comprehensive network traffic tool to keep up with data movement across the network and potential breaches.

• Integrate Security Concerns Into Your Development Cycle
When planning out the stages of development,whether you work on an agile process or a standard model, you’ll need to consider the security implications of each part of your application. Starting from the earliest conversations about requirements and design all the way to the final testing phase,security concerns should be at the forefront of your thought process from the very beginning. In particular, security testing should be as important as usability testing.

• Be aware of the security implications of your coding conventions
Even simple coding conventions such as file locations can have large implications in terms of the security of a given file. While you attempt to create a stable code base by integrating standard practices such as basic password protection,make sure that you block all routes to sensitive files,not just standard ones.

• Test for major, known sources of hacking
While there will always be unknown vulnerabilities that will require major testing and upgrades, you should always protect against the well-know, major holes that often arise in web applications,In particular,design your application to withstand SQL injections, remote code calls, format string weaknesses as well as XSS (Cross Site Scripting.)

This post was written by Maya Richard, who primarily writes about high speed internet deals . She can be reached with feedback by combining her name and gmail.com

Get Your Kicks on Route 66 was a popular song and rhythm and blues standard from the 1940’s. For those in the application security space, their idea of kicks on 66 may be found in the PCI DSS requirement for code reviews and application firewalls, specifically DSS requirement 6.6. PCI 6.6 is significant in that it, combined with OWASP may be the biggest forces to advance application security in recent memory.

Application security is a big deal and that is why it is at the heart of the Payment Card Industry (PCI) security standards and requirements.

Requirement 6.6 became mandatory in June and requires the validated security of web-based applications. Requirement 6.6 requires organizations that process credit card transactions to address the security of web applications, either via manual or automated source code reviews or vulnerability scans, or via the installation of a web application firewall between a client and application. In the US alone, there are a huge amount of merchants that not must deal with application security, something many of them have never thought of until PCI made them wake up from their slumber.

There is a plethora of information available on the web regarding 6.6, so it is not necessary to fully repeat that here. But in a nutshell, the application code review requirement mandates organizations to meet this requirement 6.6 via an application code review or automated vulnerability scanning tool to identify application security issues.

The requirement to have a web application firewalls in front of web applications are to ensure that attacks can be blocked before credit card data is compromised. A web application firewall can also mitigate the risk of an insure application, in that it can detect and block attacks before an attack can occur.

Its been known for decades that the basis of nearly every software vulnerability is insecure or poorly written code. Yet for decades, application security has been ignored. PCI 6.6 is the long-awaited wake-up call for application security. Go get your kicks.

Ben Rothke is a security consultant and author of Computer Security: 20 Things Every Employee Should Know.

I was fortunate to attend this year’s OWASP  Web Application Security conference in New York city.   It was a fantastic experience where  I networked with some really interesting and nice people, participated in intriguing talks about application security and was introduced to some security vendors who captured my attention.  I chatted with Jeremiah Grossman from Whitehat security.  Jeremiah has contributed greatly to the world of web application security and is well known in the community.  You can visit his blog here.  OWASP, which stands for Open Web Application Security Projects, is an outstanding organization whose mission is to educate organizations and individuals around the world about Web application security through various means including articles, methodologies and tools.  OWASP set an industry standard with their OWASP Top 10 Web application security vulnerabilities.  In a previous post I talked about WebGoat which is created and maintained by OWASP.   In that post I discussed SQL injection, which is one the of the OWASP top ten “vulns” (vulnerabilities).

Fortify was one of the vendors I met.  I had a nice talk with Erik about Fortify and the solutions they offer companies.  As it turns out, unbeknown to me, my company has an enterprise site license from Fortify.  The suite of products is called Fortify 360 and one of the features allows organizations to conduct static analysis of an application’s source code.  Later in the conference I met someone from my organization who also mentioned that we have a site license and told me how to go about getting the Fortify source code analyzer installed on my machine at work.  He also gave me a demo of the product.  I really appreciate his involvement in assisting me with Fortify.  Getting my security fix at work is a big milestone for me.

I wanted to share my initial experience with Fortify’s audit workbench (code scanning product).  My first code scan using this product was WebGoat application.  What better way to prove that a code analyzer is up to snuff than to use it on a web application replete with known vulnerabilities.  It turns out WebGoat is a demo application included with the Fortify product.  I pointed the Audit Workbench to the directory where the WebGoat source code resided on my PC and it started it’s thing.   Below is a screen shot as the scan is taking place:

Ok , here is the summary of issues that Fortify found after the scan completed.

Notice how the issues are broken down by Hot, Warning and Info.  The Hot issues are known vulnerabilities that are considered critical and can be exploited.  You can see the different classes in the left upper corner; Command Injection, Cross-Site Scripting etc.  We discussed SQL injection in the WebGoat application on a previous post so I thought it would be cool to show you what Fortify found for this class of vulnerablity.  I  drilled down into the SQL Injection section and whala! take a look at this!!

Remember that I wrote, “SQL injection vulnerabilities are remedied by sanitizing the user supplied input. “  Fortify found that exact problem in the code; sanitizing user  input was not occurring.  Just in case you can’t read it in the Details section,  it says, “On line 166 of Login.java, the method login_BACKUP() invokes a SQL query build using unvalidated input. This call could allow an attacker to modify the statement’s meaning or to execute  arbitrary SQL commands”.  Exactly what we demonstrated in the SQL Injection post was possible!

Here is another “Hot” issue that Fortify uncovered that I want to share.  Take a look at the  screen shot below:

This is more stupidity than an explicit vulnerability.  In the highlighted  line of code there is a Database connection being made and the username/password is hardcoded.   The reason why this isn’t smart is that usernames/passwords can change often and each time changed would necessitate a programming modification.   I know from experience as a Developer that where, applicable, one should always put config values like these username/passwords in config files.

So far, my experience with the Fortify product has been very positive.  I plan in the future to use the analyzer against my own code to ascertain the vulnerabilities in the code that I write.  As a developer, it is a challenge to meet deadlines and write securely by thinking like an attacker.  Fortify is a good tool to make this possible.

Steve Gibson from GRC.com provides a free port scanning tool called ShieldsUp that I was playing with the other day.  You can perform the scan of your network here Before doing the scan, make sure you have permission from your network administrator since  ShieldsUp will probe ports of the IP address that your browser made the connection from and therefore,  can trip your company’s IDS.  Of course, if you’re doing this from home you will not have to concern yourself with this; just click on the link and proceed with the firewall check.  It’s good to know that this service cannot be used as a hacking tool like NMAP since one cannot scan a specified IP address.

We talked about egress filtering in a prior post - you can refer to that here as a refresher.  A port, also referred to as a software port, is a logical point on the computer where a remote connection takes place.   A popular port number is port 80, where you would typically run the webserver service.  As you read this page, your computer connected to this blog’s Webserver on port 80.  Once the connection on a port is made between a remote computer and the host computer communication can be begin between the two endpoints.  Besides a Webserver, there are other legitimate situations where a service would run on a computer and listen on a port for a client to connect.  For example, the programs like Remote Acess and Filesharing, as well as others, will need to listen for incoming requests.  In order for a remote machine to make a connection on your computer they would need a port or a “window” to get in.  It becomes essential to be aware if such a window to your computer exists and if it’s open and not needed, then it should be closed immediately. 

Most of us home users use some sort of router.  A router allows us to share connections between multiple computers either wired or wireless, which comes in handy these days where it’s quite typical to find more than one computer in today’s homes.  Another feature of the router is that it acts as a firewall between the internet and your computers on your network.  Found this definition of a firewall at GRC.com:

“A firewall ABSOLUTELY ISOLATES your computer from the Internet using a “wall of code” that inspects each individual “packet” of data as it arrives at either side of the firewall - inbound to or outbound from your computer - to determine whether it should be allowed to pass or be blocked. “

So I recently switched my internet service from FIOS to Cablevision.  Cablevison installed the cable and connected our MAC to the Internet without supplying a router.  I didn’t have a chance to get a router yet and our Mac is now directly connected to the Internet.  I’m not worried since our  MAC has a built in software firewall, more on that soon.   So I decided to run ShieldsUp to see the status of my ports prior to hooking up my router.

The test checked all the service ports 0 - 1055.  As you can see in the screenshot,  I recieved almost all blue boxes (representing ports)  with a few green and a “FAILED” rating.  What do the colors blue, green and red mean ?  OK, red means the port is open and listening for incoming connections and ready to serve, which, remember isn’t a bad thing necessarily, it’s only  bad if you aren’t aware of any services that should be running.  Blue means that the port is actually closed and no service is running on that port, which means that no connections can be made. That’s good.  Green is “stealth”, a term Steve Gibson coined.  A port is “stealthed” if, when probing the port  on the remote computer or router, there is no response at all. There  is complete silence on the wire.  There is  a debate in the TCP/IP Internet world regarding the notion of “stealth” vs. closed ports.  Steve felt that a TCP/IP port shouldn’t respond but rather drop the request completely.  In his opinion a “Stealthed” port is better than a closed port.  If a port responds that it is closed that, in itself, tells the remote machine that there was a system on the other end that exists and is “out there”.   If your system is completely “Stealthed” a hacker wouldn’t  even know if your system was actually connected to the Internet.  Steve feels that this added layer of privacy makes it more secure.  The “FAILED” message that I received is indicative to Gibson’s “True Stealth Analysis” which is why I recieved a failed rating from this tool. 

I did some further reading into the MAC firewall and was surprised to learn that the Leopard OS firewall is turned off by default.  Again, if you’re behind a Router (which I was before Cablevision),  there is no need for concern since the router is a firewall.  However, if you have a laptop and connect to the internet in potentially hostile environments it would be a wise thing to turn on your MAC firewall.  It is surprising that Apple, of all companies who toot their horns about security, would ship Leopard’s firewall off by default.  So, the analysis done in the screen shot above is  my MAC connected directly to the internet with no firewall running.  If there were any services running on my computer the ports would have displayed red for open.  Why the few green “Stealthed” ports?  Good question.  It turns out that these ports are actually shut down (”Stealthed”)  by my cable provider Cablevision and one of the ports is 80  - yup, I can’t run a Webserver on my MAC unless I use a router and go through some hoops to properly configure it.

Here is a screen shot of the ShieldsUp test performed on  my Ipod touch mobile browser after configuring my router.  Now, with a router in between the Internet and my the computers on my network I’m fully “Stealthed”.

I came across the perfect hands on learning tool that teaches about the common web application vulnerabilities. It’s called WebGoat, an open source J2EE insecure web application created by OWASP. The purpose of WebGoat is to educate people and organizations on the various risks that are, unfortunately, plaguing our websites. What better way to learn about website hacking than to hack an insecure website with different known exploits. WebGoat has different lessons and some hints that guide the student. It’s a great, fun way to learn web application security. You can be up and running with WebGoat in no time by downloading a zip file that contains the WebGoat code, the Java run time environment and a configured Tomcat 5.5 server. Tomcat is a free Servlet container that implements Java Servlets/Jsp specification. Tomcat also contains a Java webserver. I chose to download the war file and import it into my Java IDE, called Eclipse, so I can analyze the source code. I put my Mac to the challenge; running Eclipse and Tomcat. Using the Mac turned out to be such a pleasure since everything installed and ran smoothly. After installing and configuring everything, I was able to start the Tomcat server from Eclipse and then point my Firefox browser to http://localhost:8080/WebGoat/attack and run the WebGoat application.

Databases are typically used as the back end to web applications. SQL is a query language that is used to interact with the database. SQL Injection is a common web application “vulnerability” that allows an attacker to send data to the back end database. This “string” is then inserted into an SQL query within the application code and executed in the database. If an SQL injection vulnerability exists, then the application may be severely compromised. In some cases an SQL Injection flaw may even allow an attacker to bypass authentication schemes.  In the below WebGoat lesson the student, acting as the attacker, needs to craft some “string” that, when submitted as the “password”, allows access.

 In order to proceed with the hack we will need to alter the HTML or submit the form and intercept the request in order to modify the password field. We can alter the HTML file locally on our computer and then modify the HTML code. We will change the password field to type=’text’ in order for us to see what we type. We will also change the size of the input field (currently it’s only allows 8 characters). A quicker way I found to do this was to use an awesome “Plugin” to Firefox called Firebug that allowed me to modify the HTML on the fly. The other way to proceed with the hack would be to use a tool called WebScarab to manipulate the data passed back to the server. Notice in the screen shot below that you can now see what I typed in the password field instead of asterisks. Also, my password field now allows 30 characters. 

Here is the altered HTML in case you can’t see it :

<input type=”text” maxlength=”30” size=”30” name=”password”/>.

Why did the “password” I used admin or ‘1′=’1 allow me to logon and bypass the authentication? We need a little background first on basic authentication for websites. The “password” supplied by the user needs to be verified that. indeed, it is the correct password for this user and whoever is logging on is who they say they are. This is done by querying the database and passing the supplied “password” as a parameter to the query. Here is a simple SQL statement that might be constructed in a web application:

SELECT * FROM user_data WHERE password = ‘?’ and username=’admin’

If the query returns the record from the user_data table then we have a match on the user’s supplied password. If there is no match, then the authentication should fail and a message should be sent back to the user as “Login Failed”.

Now let’s substitute the “password” I supplied into the query:

SELECT * FROM user_data WHERE password = ‘admin’ or ‘1′=’1′ and username=’admin’

The or ‘1′ = ‘1′ makes the entire query true, which returns the user admin record and bypasses the logon scheme. With this crafty string we have successfully exploited the SQL injection vulnerability. SQL injection vulnerabilities are remedied by sanitizing the user supplied input. In the above example, if the server side code had some kind of logic to reject the single quote, our method of attack would have been foiled. In fact, there should be a series of validations for the characters that are white-listed versus those that are not allowed and in this way, an invalid character would be stripped out. The fundamental concept here is that only server side code can thwart attacks such as the SQL injection since, as we demonstrated, the client side code can be easily modified. That’s why it is essential that all input validation is performed on the server side. With some knowledge of these types of attacks and diligence at the development phase, SQL injection vulnerabilities can be avoided.

Wrote a guest post about “301 redirects“  on my buddy, Shimon Sandler’s blog.   Shimon is very well known in the SEO community and his blog has 1000+ subscribers.  It is a great resource.

Thanks, Shimon, for giving me the opportunity share a post with your readers.

Today we’re going to continue our discussion on the Yubikey from Yubico. I received mine in the mail a few weeks ago and had the opportunity to play around with the device a bit. Many people were attracted to the Yubikey because of it’s cool, tiny keyboard - so they ordered them. When it arrived they plugged it into their computers and touched the green surface which then spits out a 44 character encrypted one time password. That’s all nice and very cool but now what? How can this very innovative security token that is a tiny USB keyboard be put to good use? I, therefore, devised a way to prove that this cool token can really deliver. My plan was to customize this blog’s “admin logon” and incorporate the Yubikey authentication as an added layer of security.

Good news, Yubikey authentication is open source! This means that developers are able write code both on the client side as well as the server side to leverage the Yubikey in their own environments. There are not too many options for do-it-yourself hardware authentication solutions! Yubico offers sample code in a variety of languages that can help you get going. You can also authenticate against Yubico’s authentication server, hosted by them. This would come in handy for companies that plan on implementing their own server authentication, however, are not there yet and would like to test their client side code. In my case I decided to authenticate against Yubico, since it’s simpler and quicker. There is a downside to this approach that is worth mentioning. If I wanted to log onto my blog’s “admin panel” and for some reason the Yubico authentication server was down, I would be locked out of my blog’s admin panel.

This blog uses Wordpress, the popular open source PHP blogging software. Modifying the admin logic to include the Yubikey as a 2nd level of authentication was very easy. I utilized the code written for PHP. First, I dropped in the Yubico class on my server. I then added in some code to the wp-login.php file.

Here is the function that calls the Auth_Yubico class:

function verifyYubikey ($token) {
global $error;

$yubi = &new Auth_Yubico(’77′,’5dFRPaFvjBvwiiB023ZWu4Qb++U’);
$auth = $yubi->verify($token);
if (PEAR::isError($auth)) {
$yub_error = $auth->getMessage();
$error = __(’<strong>ERROR</strong>: ‘. $yub_error);
return false;
} else {
return true;
}

}

Here is where I modified the logic for logging on in the wp-login.php file.

if (verifyYubikey($user_yub) && wp_login($user_login, $user_pass, $using_cookie)) {

I verify the yubikey string prior to verifying my static password so people can try it out by putting in a password and see what errors are returned back from Yubico’s authentication server; more on that shortly…

So, how does the Yubikey work? We talked about asymmetric encryption in a prior post. Each Yubikey contains a unique private key that encrypts some data, turning it into the encrypted OTP (One Time Password). The Yubikey uses a conversion scheme to ASCII, which they call mod-hex. The 44 character blob is made up of 12 characters plus the 32 character OTP. The first 12 characters never change; they are your Yubikey’s unique id. So you have the 48 bits plus an AES encrypted 128 bits sent over to the authentication provider (in my case, the Yubico server). Yubico then does a lookup with my unique 12 characters and pulls the “public” key to do the decryption. Now, if the authentication side is able to decrypt this blog then you are successfully authenticated. After decryption you have 128 bits of cipher text. Besides containing your unique id, the cipher text also contains some additional useful information about how your Yubikey has just been used. For example, the time-stamp of when the OTP was generated is included, as well as a session “use counter” showing how many times you generated an OTP. This information can be used to thwart some sneaky phishing attacks. Another thing to note is that your secret AES key in the Yubikey is never able to be read out; nothing you can do to the device can force it to give you it’s secret key. All in all, this hardware solution is extremely secure.

Below are two Yubikey passcodes generated from my Yubikey that I used to authenticate myself when creating this post. I highlighted the first 12 characters, my unique serial number indentifying my Yubikey. You can copy and paste the string in the Yubikey field on my admin page and then type in anything for the static password (logic for verifying Yubikey is done prior to the static password as you can see in the PHP code above).

jdteklknnhcffbfgjebejhbbgnrtrevingnldlctiulj
jdteklknnhcfnfidtedkcelbrkvngurddrclghnidgfh

To make sure the responses come from Yubico, they offer you the ability to create an id with a shared key. When you authenticate, there is an extra field returned to which you can apply a signature algorithm. To apply this algorithm you use your shared key to validate that the response actually came from Yubico. In the code of the “verify method” above I included my id of 77 and the shared key that was assigned to me. I just tried changing the shared key by adding a “1″ to the end of that string and wasn’t alerted that my signature algorithm failed; which it should have done. Perhaps I’m doing something incorrectly; feel free to comment. I’d like to say thank you to Simon from Yubico who was responsive to the questions I posed. Yubico also set up a forum where you can learn more about Yubikey.

Worked on an interesting assignment at work the other week. A little background first. TIBCO is a middle-ware solution used frequently in the financial industry. Tibco allows legacy applications to talk or communicate with each other. For example, a process in C++ can publish a TIBCO message that can be picked up and processed by a Java process and vise-versa. TIBCO is set up to run throughout the firm, across many different applications. TIBCO can be set to run in two modes; ‘reliable’ and ‘certified’ mode. Reliable messaging is not concerned with the receiving party actually receiving the message, it’s a publish and forget. If the recipient picks up the message that was sent, fine. If the recipient didn’t pick up, also fine. That is not the publishing process’ concern. Certified messaging, on the other hand, makes sure the receiving process or processes (multiple processes listening) actually get the message. If the receiver didn’t get the message because the process crashed, messages will be queued up so that when the process comes back up, the messages in the queue will be published out again.

The main process that runs on Unix talks to the Front-End (FE) trading system in reliable mode. The messages that are published to the FE are order acknowledgements, executions, tickets, amongst other types of messages. The FE processes these message in real-time. You can imagine all these messages being published out to 1000+ trading FE’s. So it’s possible that all these processes running might overload the network, especially in high volume trading times. We, therefore, needed a way to ease the amount of data sent over the wire to all these FE’s. I decided to try good old compression similar to ZIP and GZIP. I implemented a solution in JAVA that compressed the Java String message before it was published out over TIBCO to the FE. The FE needed coding modifications for this solution, as well, to handle the compressed messages and perform the decompression on the fly. I also made sure that this functionality can be turned off at run-time, just in case something unforeseen happened and we need to revert back to sending messages uncompressed.

Data compression reduces the size of data by using a compression scheme. There are many different types of compression algorithms that are used differently for certain types of files. The table below shows the compression rates of a few sample messages that were compressed using “on the fly” compression. Notice that the bigger the message, the better compression rate you will get. The reason is that “on the fly” compression uses a substitution scheme, so the more repetitive the text, the better compression rate you will get.

On Securitynow podcast #141 Steve Gibson talks about his experience at RSA Conference 2008 a few weeks back. The RSA Conference is the largest of it’s kind in the world focusing on information security. I mentioned to a friend that I’m going to be at the RSA Conference in 2009 and I’m going to leave the kids somewhere and bring my wife. Ok, ok - that’s pushing it.Steve gave out a url which takes you to RSA conference Keynote speakers so you can watch at your leisure. There is one really fascinating keynote address by Jeff Hawkins about brains and computers (AI) that is worth watching.  Jeff Hawkins co-authored a book called, “About Intelligence”.

At RSA Steve stumbled on a really cool new product called the Yubikey from a Swedish company called Yubico. The Yubikey is a very small USB authentication device. You plug it in to your computer’s USB port and then go to, say, a website that was all set up to support Yubikey. Touch the device and it will spit out a really long one time password sequence. If you have the the device that is associated with you (based on the devices serial number I would guess) then you are authenticated. In authentication speak this form of authentication would be something you have, while your static password is something you know. The really cool thing about this device is that the Yubikey contains a tiny keyboard so you don’t have hardware compatibility issues. I need to learn more in order to fully explain how this works. What better way to learn about the product than to implement it. We talked about securing my blog’s “Admin panel” in a previous post. I have username/password and for a 2nd factor authentication I can use the yubikey. I sent the company an email the other day expressing my interest in the product. I got a response back from the CEO.

“Thanks for your interest in Yubico….Since Steve Gibson sent his latest SecurityNow! podcast interest in our product has greatly exceeded our expectations. We are working hard to catch up with demand and sincerely apologize to all of you who are still waiting to receive shipments from us. We expect to be caught up within the next two weeks. ……. “

I’m sure the CEO is happy she met Steve at RSA. I’ll keep you updated on my progress in implementing the Yubikey on my blog’s “admin panel”. We also need to discuss “openID” since the yubikey is openID compliant. In short you can use your Yubikey when logging onto sites that support openID for an added level of security. Until next time..

***** Follow up ******

New post on my Yubico Impementation.