Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Whether this is about ha.ckers.org, sla.ckers.org or some other project you are interested in or want to talk about, throw it in here to get feedback. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
Secure Feeds & Feed Reader
Posted by: brobdignagian
Date: June 04, 2009 02:12PM

Hi,

I'm new here and wanted to get some feedback on a project I'm working on.

It's a system with 2 parts:

1. A web app where users can log in and publish short messages through a feed, probably RSS, but maybe another XML format.
2. A desktop client where users can subscribe to the feeds and read them

The feeds are going to contain private/sensitive info, so I need them to be secure.

My plan as of now is password protection + SSL on the web app side, and htaccess authentication (Basic) + SSL in the feed reader.

I may end up just using blogging software like Wordpress as the RSS entry/publishing system, and use it's password login setup. However, I could code up something custom if that would be more secure (preferably in PHP+MySQL).

The desktop feed reader app is written in Adobe AIR, because it needs to be multi-platform and lightweight.

Does this seem like a secure setup? Any feedback would be appreciated.

It may also be possible to limit RSS feed access based on the user's IP, but I'm not sure if this will be doable in all cases.

thanks.

Options: ReplyQuote
Re: Secure Feeds & Feed Reader
Posted by: wireghoul
Date: June 10, 2009 08:39PM

Security went out the window as soon as you said Adobe Air...

Seriously tho, you might want to look into the tons of work already published on the dangers and shortcomings of basic auth. Limiting by IP becomes an issue when (transparent?) proxies enter into the equation (hello AOL!).

Air has a very short and not entirely successful security history, so I wasn't just joking. But the desktop client issues aside, we are a web app sec forum...

Here are some attack vectors on your publishing web app;

Arbitrary file writes if you use files, or sql injection with database
Injecting html, xml, js into the rss feed for XSS/DoS
Abusing value pairs to attempt publishing in other peoples feeds
Injecting self referencing content (i frames?)causing the desktop app to repeatedly download the RSS feed for DoS condition.
Publishing post containing embedded content that are either very big files (dvd isos?) to fill up the clients HDD or a very large number of large images to consume bandwidth (edos)
Publish large values to buffer overflow the desktop client
Publish goatse pics (marblecake attack)
Then there are your usual suspects, session fixation, csrf, et al.

Additional vectors for abuse would become clearer with more details or access to the web app, but that should be enough to get you started. I would recommend that you read the security section of the manual for whatever programming language you decide to use and perhaps the OWASP guide as well.

[www.justanotherhacker.com]

Options: ReplyQuote
Re: Secure Feeds & Feed Reader
Posted by: brobdignagian
Date: June 18, 2009 12:03AM

Thanks for the response -- I forgot to follow the thread and just noticed it.

This is a useful list. I've dealt with most of these attack vectors in previous work, and they all generally have to do with malicious content posted through the web app. They're similar to vulnerabilities you have in a form posting to a database, where that content is later published.

It seems like I can do a lot to prevent most of these vulnerabilities in the design of the web app. I can definitely design the app so that it's text only, not allowing files or images to be posted. I can't avoid URLs, but I don't necessarily have to make them clickable. Either way, I won't be responsible for what happens when users click on links. I can also definitely do my best to strip out any tags in a post, which takes care of html & xml injection. JS injection would be slightly harder to catch, but stripping or escaping all or some of the necessary syntactic elements should render it mostly harmless.

I'll definitely consult best practices for the language (mostly likely PHP at this point) and OWASP, but thanks for the tip.

For the most part, these vulnerabilities with the content aren't huge concerns, because the web app isn't intended for the general public. It's going to have a relatively small user base publishing message feeds to a potentially large group who have the desktop client.

Also - I realize this is not the place for AIR discussion, so I won't ask any AIR-specific follow-ups here, but any links to good articles on AIR security issues you've seen would be great. The main attraction for me is that I have to make this thing multi-platform and AIR seemed like the easiest way to do so without doing it in Java, which could be clunky.

But I was under the impression that although basic authentication on it's own is clearly not secure, basic over SSL is, as it's encrypted. Is that not true?

That said, I don't think it will be a problem to use another authentication method with apache if need be. I haven't used it before because I've always used Basic over SSL, but mod_auth_mysql lets you use AES encryption and seems like it's not a huge deal to set up.

thanks again.

Options: ReplyQuote


Sorry, only registered users may post in this forum.