About a year ago, javarss.com got hacked. Back up, for those who do not know that Javarss is, it was a simple site that had a really nice AJAX driven interface containing RSS feeds from all of the major Java websites. It was simple, just a bunch of links, organized by Website, and when you hovered over them, you'd get a brief synopsis of what the article was about. A one stop shop for Java info and advancements. For busy people, like me, it saved me the trouble of surfing through a dozen or so web sites each day to to find interesting topics.
Well, it was great, until it got hacked back in March 07. The hacker go into the server, and replaced the javarss page with a evil (and kind of neat) looking page, proclaiming "Hacked By Secretary Lucifer". The hacker even left a couple email where the server admins can contact them, possibly about getting their access back. Well, a couple months later, the server admins finaly gain control again, but they never bring Javarss back up. All that remains is a message that reads "We are restoring the site. Please visit us later...". This has been like this for about 6 months. I would love to know how the hackers got in, I love learning about that stuff.
So, what happened? I mean, c'mon, they are just loosing money, and loosing loyal followers with each passing day that they stay closed. I can honestly say that since their demise, I have started to frequent DZone a lot more. DZone is a similar concept, but with a much more rich interface, and they are find articles for languages other then Java. After all, we are developers, not Java Developers. So, I highly recommend you check it out if you haven't already.
Tuesday, December 18, 2007
Friday, November 16, 2007
Uggg, blogging is hard
Wow, I haven't posted since January. I actually forgot about this blog for a while. I was about to delete it, figuring that no one is reading it. Besides, I never post to it. Is it because I don't have enough time? Nah, I don't think that is the problem. I think that it has a lot to do with the fact that I wanted this blog to be something epic. I wanted to reach the average coders out there who are too timid to risk being teared appart on a Linux user forum by asking a question about PHP. But I wanted it to be informative to everyone like Ben Forta's blog, or the Coding Horror blog (seriously, you should check this one out). And in doing so, I was unconsciously putting the concept of this blog up on a throne. The importance I placed in my message is what was causing me to delay my next entry. I was too nervous that what I would write wouldn't be important enough, or would be considered as child's play to some of the more advanced coders out there.
But I've realized something over the past couple months. Given my experience and education, I am actually on the same playing ground as many of the advanced coders. They just have more confidence in what they say than I do. So, the trick is to post blogs, and keep posting. Not worrying about whether or not my information is going to be an epic, or an awe inspiring message of programming genius. Hell, if I can help one person set up Tomcat with a project that is a non-war deployment, and have their servlets and JSPs reloadable, then I think I've done my job.
That reminds me, along with my previous posts about Tomcat 5.5, make sure you set the reloadable attribute to true in the context.xml file under the $CATALINA_HOME/conf directory.
<context reloadable="true">
That will aid in making your classes (servlets) reloadable without restarting the server, or using WAR file deployment.
Till the next time. Keep coding.
But I've realized something over the past couple months. Given my experience and education, I am actually on the same playing ground as many of the advanced coders. They just have more confidence in what they say than I do. So, the trick is to post blogs, and keep posting. Not worrying about whether or not my information is going to be an epic, or an awe inspiring message of programming genius. Hell, if I can help one person set up Tomcat with a project that is a non-war deployment, and have their servlets and JSPs reloadable, then I think I've done my job.
That reminds me, along with my previous posts about Tomcat 5.5, make sure you set the reloadable attribute to true in the context.xml file under the $CATALINA_HOME/conf directory.
<context reloadable="true">
That will aid in making your classes (servlets) reloadable without restarting the server, or using WAR file deployment.
Till the next time. Keep coding.
Friday, January 05, 2007
Dead Winter Dead and Web Application Security
Wow, I haven't added to this blog in over a month. The ironic thing is that the winter time is usually the slowest time for a developer who works for the government. Especially where I work. The organization that I work for are re-organizing themselves, and have no time to look at proposals or statements of work. So, we just sit and wait for something exciting to happen. Since we are on a fixed price contract, we still get paid.
Although, times haven't been that slow for me at work, and home. My wife, kids, and myself have all been sick. The relatives came in from out of state. And the holiday season in general makes simple tasks a mad house. But enough of this non-technical stuff. Anything interesting?
Well, yeah, kind of. I was assigned a task to look into new security requirements for many of our apps. These requirements were signed by President Bush about 2 years ago. Some are simple, like session timeouts must be set at 30 minutes, and tracking all access to "Personally Identifiable Data" (aka Social Security Numbers). Some were a little more complex, like enforcing 2-factor authentication. Since many of our apps deal with secure data, and because of the whole VA Laptop thing that happened last summer. My group needed to do something, fast. For all new apps, the security requirements have already been put in place, but the older apps needed to be updated.
The interesting part was working on a solution for enforcing 2-factor authentication. Typically, a website has 1-factor authentication, a password to proove that the user is valid. 2-factor authentication is a way of not only proving the user is valid with something that they know, but to request something that they have as well. Things like smart cards, biometrics, and security tokens are just a couple ways to help prove that you are who you say you are. Our government client decided on using security tokens to solve this problem, in the short term, at least.
The security token works on the concept of this little device that displays a 6 digit number, that changed every minute. A user would enter a pin and the 6 digit pass code to prove their identity. However, these little devices are about $70 a pop. Considering that hundreds to thousands of people use our systems, that can get costly. Well, it turns out that most people who use the systems, don't need to have access to the secure data anyway, they only need access to the non-secure data on the sites. We have user roles to enforce who can see what. However, there can be 2 people on the same role who can see the same data, but only one needs to see the secure data. We wanted a simple way of hiding the secure data, without recreating the users into new roles, and causing as little modification to the code as possible. Therefore, only a small fraction of people will need the tokens.
All of our security and user authentication code was generated through ColdFusion/Java and an Oracle back end. The use of the ISAPI dll that came with the secure tokens wasn't useful for us, and I couldn't find anything on the net about this type of implementation. So I had to design our own way of doing this. I will discuss my solution in my next post. If anyone has run though this situation before, I would love to hear how you handled it.
Although, times haven't been that slow for me at work, and home. My wife, kids, and myself have all been sick. The relatives came in from out of state. And the holiday season in general makes simple tasks a mad house. But enough of this non-technical stuff. Anything interesting?
Well, yeah, kind of. I was assigned a task to look into new security requirements for many of our apps. These requirements were signed by President Bush about 2 years ago. Some are simple, like session timeouts must be set at 30 minutes, and tracking all access to "Personally Identifiable Data" (aka Social Security Numbers). Some were a little more complex, like enforcing 2-factor authentication. Since many of our apps deal with secure data, and because of the whole VA Laptop thing that happened last summer. My group needed to do something, fast. For all new apps, the security requirements have already been put in place, but the older apps needed to be updated.
The interesting part was working on a solution for enforcing 2-factor authentication. Typically, a website has 1-factor authentication, a password to proove that the user is valid. 2-factor authentication is a way of not only proving the user is valid with something that they know, but to request something that they have as well. Things like smart cards, biometrics, and security tokens are just a couple ways to help prove that you are who you say you are. Our government client decided on using security tokens to solve this problem, in the short term, at least.
The security token works on the concept of this little device that displays a 6 digit number, that changed every minute. A user would enter a pin and the 6 digit pass code to prove their identity. However, these little devices are about $70 a pop. Considering that hundreds to thousands of people use our systems, that can get costly. Well, it turns out that most people who use the systems, don't need to have access to the secure data anyway, they only need access to the non-secure data on the sites. We have user roles to enforce who can see what. However, there can be 2 people on the same role who can see the same data, but only one needs to see the secure data. We wanted a simple way of hiding the secure data, without recreating the users into new roles, and causing as little modification to the code as possible. Therefore, only a small fraction of people will need the tokens.
All of our security and user authentication code was generated through ColdFusion/Java and an Oracle back end. The use of the ISAPI dll that came with the secure tokens wasn't useful for us, and I couldn't find anything on the net about this type of implementation. So I had to design our own way of doing this. I will discuss my solution in my next post. If anyone has run though this situation before, I would love to hear how you handled it.
Subscribe to:
Posts (Atom)
Posts
