Are component parameters secure?

[Jon Lackey @zuno]

Hello all.

I have a component that is using the PayPal API to process payments. I
need to store the API username, password and API signature somewhere.
Is it secure or secure enough to store them as component parameters?

Thanks for any and all suggestions.
-Jon

[Hannes Papenberg]

Yes. You need the data in cleartext somewhere and that means that you
have to store it as plaintext somewhere. In that case it doesn't matter
if you put it in a file or a table or in such a INI-field.

Hannes

Jon Lackey @zuno schrieb:

[Andrew Eddie]

It depends on what you mean by secure.

Any PHP from any extension can connect to the database and
theoretically access that information. It's hard to quantify the
risks but it would become a problem if the attacker is able to create
an SQL injection that exposes the data in the component params field.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/11/11 Jon Lackey @zuno <webmo...@gmail.com>:

[Jonathan Lackey @zuno]

Thanks Hannes and Andrew.

I'm not very well versed or knowledgeable in the security area. Does anyone know of articles, sites or books that cover security for extension development?

-Jon

[Terry Szykowny]

Neither am i, but i guess for extensions the same rules count as for php (and ajax, if u use it) so you can find loads via Google about "php, security" i.e... Google "sql injection", too. It's easy to avoid by following a few rules as far as i know.

11. 11 2009 12:19 AM schrieb am "Jonathan Lackey @zuno" <webmo...@gmail.com>:


Thanks Hannes and Andrew.

I'm not very well versed or knowledgeable in the security area. Does anyone know of articles, sites or books that cover security for extension development?

-Jon

On Nov 10, 2009, at 2:28 PM, Andrew Eddie wrote: > > It depends on what you mean by secure. > >...

[Amy Stephen]

You might see if OpenID offers any PayPal integration. Or, maybe Verisign. Some type of integrating, security web service that you can integrate into your Web site that is designed to protect credentials.

[Oli Griffiths]

Another option that you may look at is encoding the user details before storing them and then decoding them when you get them back out.

There are various ways to do this, a base64 encoded string using a salt that is only known to you, or perhaps stored on the filesystem.
The other is to use aes_encrypt and aes_decrypt, both mysql funcitons often used to store credit card info in the DB and mysql quotes: “AES_ENCRYPT() and AES_DECRYPT() can be considered the most cryptographically secure encryption functions currently available in MySQL.”:
http://dev.mysql.com/doc/refman/5.1/en/encryption-functions.html#function_aes-encrypt

Hope this helps.

Oli

[Sam Moffatt]

At the end of the day you get to a point in web application security
where encryption doesn't become worth it. You can only prevent people
from getting in through the untrusted pathways, at some point you
require a trusted pathway. If something compromises a trusted pathway
then regardless of what you've got you will eventually be compromised.
Of course you can put layers in the way however if your PHP is going
to be accessing this data back then any other PHP script that gets
onto your server will have access to that.

There are models around that, for example where I work we have "API
servers" for different systems that server a dual purpose: the simple
is that they're a level of abstraction between items so we can easily
update the behind the scenes code and they also serve a security
functionality. They have very limited services running on them, the
code that runs there is more highly verified and has a limited API to
ensure stuff that shouldn't get in doesn't and they implement
security. Depending on what you're doing you can shuffle off details
there and not provide a way of obtaining them back presuming your
security model works that way. Just the other day I spec'd out a new
system that we mediate communication with Google Apps' Web Services.
This means that if one of the publicly accessible machines are
compromised we don't immediately lose the credentials to get access to
those systems. They're also protected strongly in a network
perspective as well so a simple PHP vulnerability where they can dump
files onto the web accessible server won't cause a loss of those
credentials (of course that doesn't mean they can't impersonate the
service and obtain a high level of information, it does however limit
their ability to cause damage plus the service credentials remain
secret which since Google Apps is externally accessible by definition
is a good thing). The environment I'm in has a reasonably high level
of security thinking with around 10 different firewalled zones for
different services and restrictions on how they behave - perhaps the
middle of the road for a secure environment.

So at the end of the day, you can go overboard and perhaps you've got
an environment that works in. Realistically however the average
Joomla! site doesn't have that level of security and storing a plain
text copy in your component params is no more insecure than most other
alternatives (hint: encryption works with a key, you need to store
your key where PHP can get to it, that means any PHP script can get to
the key and the secured details).

Sam Moffatt
http://pasamio.id.au