Google's Anti-Malware team is running a series of blog posts as part of Cyber-Security Awareness Month to help educate users (and webmasters) about the malware threat. One of their posts highlights some best practices for webmasters to use should their site become compromised and flagged as containing malicious code.
This is something I came across at work that I thought I would share, because at first, it had me scratching my head.
Internally, Adobe AIR uses webkit as a "browser" which is great, and as expected, it actually behaves like a browser, including cookie support for access to external resources. Which means that when you are making remote calls to resources, you can use cookies to maintain sessions, or for information tracking.
So let's be honest. Users are users. If they knew what they were doing, we would not need to grumble about them and make fun of them under our breath. But they don't know what they are doing. And they never will. NEVER.
The use of JavaScript is becoming increasingly popular with the availability of incredible JavaScript libraries. These libraries make creating Ajaxified web application easy, and fun! We can use them to create interactive and beautiful applications that rarely, if ever, require the page to refresh.
A lot of the JavaScript libraries also have helpful tools and plugins to implement form validation. These tools are great, and I don't want to discourage their use, but I do want to point out that these tools ARE NOT for security and should not be used to prevent malicious data from getting to your application.
It seems like a no-brainer to me, but I will say it anyway. Code reviews are a good thing. Some people may shy away from them because it may make them feel inadequate or like they are being judged. But the idea behind a code review is to learn.
Code reviewing is a great way for a developer (novice or otherwise) to track down inefficiencies or architectural problems with their code by using the experience of other developers as a tool. We all know that two heads are better than one, right?
Failing securely is one of those things where, when you think about it, you say "duh". But I, for one, did not realize until it was pointed out to me that I was not always doing it. Let's look at an example of failing insecurely.
In this example, we have an application that has three types of user roles. The three roles are "admin", "superuser" and "user". Let's say we have a piece of content that we don't want regular users to access, so we do this:
So I recently became aware of (IN)SECURE Magazine from Help Net Security (HNS).
(IN)SECURE looks like a high quality PDF publication that covers A LOT of security topics from web application development, to network security, to operating system security. Issue #21 of the magazine was just released.
Some of the articles that interest me most, and I think would interest developers in our community are:
