Security offense!! Access denied!

[pcwacht]

Not saying I wouldn't like the new idea around issues etc.

Logic of an other solution could be:

User logs in and gets a secret key only known to server with wich it scrambles the form tags (FTAN)
This secret key is time limited, say default 5 minutes or so wich could be upped if needed, thus the ftan lifetime is limited as well

As long as the FTAN key matches with the secret key it is ok.
This way the same ftan could be used on diff pages for the same user at the same time.

Kinda like windows uses kerberos

I must say, reading all this protection measurements wich are currently build into the new core of wb, php code wich can't use includes, eval etc, FTAN per page wich obstructs multipage editing, naming the two I know about, I am starting to get less eager to see the new WB in action.

John

[testör]

Security is always a bunch of combination - have a look here: http://drupal.org/writing-secure-code
Or have a look here: http://wiki.phpbb.com/display/DEV/Function.check+form+key and http://blog.phpbb.com/2009/01/14/fighting-csrf/ (phpBB uses quite the same form-key validation as SecureForm).

[NorHei]

I see another problem coming up if WB goes for browser fingerprints to secure sessions it will become inpossible to work whith multiple Browsers.

[Ruud]

As long as the FTAN key matches with the secret key it is ok.
This way the same ftan could be used on diff pages for the same user at the same time.

The problem is that the same hacking script can first request a form page and read the correct FTAN from the returned data. Next it uses the valid FTAN for his hacking attempt.
Remeber.. WB is open source.. Anybody can see how it is done!
The only way to solve the issue is by adding a fingerprint to every form (core AND all modules) to be sure the FTAN is valid and generated from that form only.
Since this is impossible in the WB2.8.x world, the solution now is at least more than fake security.

I see another problem coming up if WB goes for browser fingerprints to secure sessions it will become inpossible to work whith multiple Browsers.

Multiple browser is no issue. They will have different sessions. The whole problem is session related.

Personally, I don't like the side effects of this solution either.. But this is the world we seem to live in.
A little bit safe, is not safe at all.
So what do we want.. A system with publicly known security holes, or a system that tries to close all holes.


Ps..
(found on J__mla docs on their CSRF security solution)

• Don't browse other sites in the same browser while you are logged into your site.
• Log out from your site after you are done.
• Don't stay logged into your site while you are not doing anything.
• Ensure that the address in the browser bar matches the address of your site.

[Argos]

I found a workaround to disable the multiple form security annoyance. See https://forum.WebsiteBaker.org/index.php/topic,21456.msg144676.html#msg144676

[NorHei]

The problem is that the same hacking script can first request a form page and read the correct FTAN from the returned data. Next it uses the valid FTAN for his hacking attempt.

Thats not entirely true .
- As those static token(TAN/FTAN) tend to have a timeout (normally about 1/2 hour) the attack needs to be run pretty close after the last logged action. Plus the guy has to klick at your malicious link whithin this time.

- A token normally is based on username or session id so its impossible to get that token in advance as you need to be logged in whith the right username. So at least you have to trick the user into doing something silly twice. 

- Its pretty easy to add the url(or maybe a formname) to the generation process of your token that way one token will only be valid for just one form

Static tokens are not completely insecure and its pretty hard to exploit em whith an automated  script but if you aim to hack a speciffic site its still an relatively easy to exploit option.

Multiple browser is no issue. They will have different sessions. The whole problem is session related.

Most(all i know) secure session scripts only only allow accessing the site only from one browser at a  time.
That way attackers that somehow capture the session cookie  they still have to get the exact browser fingerprint . (and there is only one chace to guess as session is logged off if there is a security breach)
So its impossible to access a site from 2 browsers that same time as every time you change  your browser you get logged off.

Some scripts even add an additional cookie based token that changes on every action. So if you change  your Browser you get logged off again.

@ Argos
Disabling is easy (just let the functions always return true )but its no solution . Its so incredibly easy to exploit those security holes thats its almost like a miracle noone already wrote an exploit.

[BlackBird]

As a follow-up to NorHei's explanation a question came into my mind: Does WB _really_ need this (high) level of security? Why should someone be interested in such a lot expense just to hack a simple website? The only thing is to spread malware, but there are so many sites around having no security features, so there's no need for hackers to put high effort in cracking even "simple" security mechanisms.

Don't take me wrong, security _is_ a subject and should be focused, but if it corrupts the comfort of using WB, it is the wrong way. People will go away and use a more comfortable CMS instead of WB, there's a great variety of CMS out there to choose from. Ease of use is one of the most important advantages WB has. It MUST be preserved.

[Argos]

That's my point as well. I have used WB for six years now, and never had any security related issues (as far as I know) on the dozens of sites I built. WB is typically used for small to midsized sites for individuals and (often local) small to midsized companies. These sites are not the most likely targets for hackers. Heavy security measures that impact usability are just too much for these kind of websites. I have the impression that the/some devs are so obsesed (from a technical point of view) with securing WB as much as possible, that they have lost touch with the reality of everyday WB use(rs).

Security is good, but usability should not significantly suffer.

[BlackBird]

100% agreed

[pcwacht]

More then 100% agreed

WB is simple, simple is WB
WB is ease of use, ease of use is WB

Ah well, you get the drift

John

[NorHei]

100% disagreed . As WB grows bigger and bigger there will be exploits thats almost certain.

Whats the intention to hack a WB site , same as other hacks .  To have a slave server for spamming, selling childp***, and having a place to store banking fraud pages. Cleaned up several hacked servers as they where using old insecure Wordpress versions.  

Its not hard at all to write a token system that allows a configurable number of open instances.
In fact i already done that on a framework i created for myself.

Only disadvantage is it needs you to set a name for each form you want to use it for.
so you call it  :

Code: [Select]

wb_form_token_input("MyLoginForm");
and
wb_token_check("MyLoginForm")

The need to use formnames is a sideeffect of WB not using the Apeform concept.
If you are using Apeforms you can even call it whithout any parameter.

Please keep in mind that i ripped it outof another Framework, so i am not sure if it runs whithout the framework. (Not sure if i added all necessary helper functions for example.)

[gelöscht durch Administrator]

[Stefek]

100% agree with the fact that WebsiteBaker has to be as easy and enduser friendly as possible.
Any security issue needs to be debuged, of course, but without any harm in means of less useability.

Stefek

[NorHei]

OK, was a bit late at night.
100% Agreed whith WB is simple and should stay that way.
100% Disagreed whith the idea that this is a reason for not fixing security Holes .

 

@stefek 100% agreed
 

[BlackBird]

100% Disagreed whith the idea that this is a reason for not fixing security Holes .

No one said that security holes should not be fixed. It was just said that there may be too much security - in the means of making a system as secure that it's unusable. (Like the server in the safe, switched of. The data is secure, but no one can use it.)

Please don't mix this up.

"Nach fest kommt ab!"

[Argos]

Blackbird is right. The aim is just that WB should ofcourse be as secure as possible, BUT without decreasing usability. Nothing more, nothing less. The current FTAN system does not only decrease usability, it even does that to the point of making WB buggy.

Devs should look for a security system that does not interfere with WB's high usability. Until they have found that, I personally choose to disable FTAN. But that's a decsion everyone should make for themselves.

[NorHei]

You guys are really funnie.
(Sorry, someone told me  Blackbird is a Lady?)

Instead of complaining and telling pepole to deactivate security, how about take the solution i presented and build a nice and clean replacement class for secure_form.php.

If it does not go into SVN simply present it as a patch. (Many pepole will love it )

@Argos
[text removed by moderator Argos, as it only contained unneeded heavy sarcasm and possibly dangerous info]

[Argos]

Too bad you feel so much agression about this subject and me. For the last time:

- I applaud any security measure as long as it doesn't impact usability in a major way.
- I dont encourage people to make WB less secure. I only offer the possible workaround for people who are annoyed at the side-effects of the recent FTAN -measures in the RC's. Anyone can and should decide to use it or not.
- Regular users like me cannot do anything with your posted alternative. We don't understand anything about the technical stuff, we only comment about the negative side-effects we see. You have to be a coder and part of the DEV-team to use it. So far, the devs are really quiet...

[BlackBird]

I already suggested to use SSEQ-LIB instead, as it works very well. The Devs refused to do so, they prefer the solution they created. As far as I remember, the argument was the high effort to change it again. But I think the Devs should explain their decision by themselves.

[Argos]

As any decent designer or developer knows: sometimes you have to kill your darlings, how difficult that may be.

[NorHei]

SSEQ-LIB looks interesting , did you ever looked into it to figure out how it protects against CSRF?
(Hope its not using a static token )

[NorHei]

Just checked it and its using static token   
Optionally you can set it to generate single use tokens like the ones we have in WB but whith same disadvantages...

[BlackBird]

There's an update pending, but I don't know any details. You may ask the developer.

[BlackBird]

Here's a nice explanation on how to create tokens without the tabs/windows/browsers problem.

Edit: Woops, forgot to paste the link.
http://stackoverflow.com/questions/2695153/php-csrf-how-to-make-it-works-in-all-tabs/2695291#2695291

[NorHei]

Thats  really interesting .... reminds me of selfsigning keys for websiteencryption.

[BlackBird]

It's very simple to combine different params - userid, sessionid, whatever - to a unique key that still works across tabs. It's really quick to implement, too. Can't say anything about security, but should be quite secure.