It's done, but I don't see you on the moderators list.

On the console he complains of an error syntax on line 8

How secure is this oxwall CSRF system?

Why have nobody take action fix this?

https://developers.oxwall.com/forum/topic/55811

Or is it fixed ???

OW-ghost

This is what we are checking, so far no one has managed to break the security of https://somoscd.es/testsite/

I hope that if someone succeeds, they will explain to me how they have done it to develop a security improvement.

There is another user who is trying to mess with cookies, let's wait to see if he is more successful.

Xprt   if the links are dangerous please remove them.

Thanks appreciate that.

Appxpert has fixed the syntax error, but it still doesn't work.

Clicking on the link that he has sent me by message takes me here:

Sin título.png

The admin was not logged in.

In case it is not seen in the image, the URL is this:

https://somoscd.es/testsite/sign-in?back-uri=admin%252Fpermissions%252Fadd-moderator

Accessing from another browser, I verify that AppXpert continues without being a moderator. I close this other session.

I go back to the original browser that was on this screen:

Sin título.png

and I log in as an administrator and it takes me to the moderators administration page:

Sin título1.png

As you can see, the attack has been unsuccessful, the two moderators there are those who were already there before.

For now, OxWall + https://owspain.com/magazine/articulo/view/8

is passing the tests.

The challenge continues!

Analyzing the link that AppXpert has sent me, it exceeds 78 of the 79 virustotal.com tests, only 1 of them has detected "Phishing"

Sin título2.png

This very well.

The link shortener he has employed, rb.gy, passes the tests of

http://www.checkshorturl.com/expand.php

Sin título3.png

but not from https://unshorten.link/ is able to decode it but shows that it is a secure link:

Sin título4.png

If I manually access the URL

https://somoscd.es/testsite/admin%252Fpermissions%252Fadd-moderator

or to:

https://somoscd.es/testsite/admin/permissions/add-moderator

which is the same, leads me to:

https://somoscd.es/testsite/admin/users/moderators

and no moderators have been added either.

Remember that if you manually add a moderator, they receive moderator permissions for all plugins EXCEPT "Admin", so they cannot access the control panel either, this is a point in OxWall's favor

Thanks for sharing Patricia... that is good news.

Now seeing that this topic is about CSRF, one rule of thumb that i go by fellow developers is that i never show the whole CSRF token to the user.   They only see part of it in the form source.  That is because IMO it adds extra security to hide part of it, and they really dont need to see the whole token.   Any time i code for CSRF i also break the token into pieces, show only part of it in the form source, and then put the token back together after the form is submitted, then validate the token from there.     IMO (and some disagree) this offers better security. 

The day will come when the ability to exploit a token is possible and used by hackers.   When that time comes i will already be prepared because they cant see the whole token.

As an example remember when session id's were the hot topic, it was suppose to be so secure, and yet it did not take long for the bad guys to figure out how to exploit those either.   So now we no longer show session id's in url data streams.

there is easy fix that i can share to they who interested secure they site from insight

Patricia Zorrilla I did disable the CSRF TOKEN using your method in my testing website and the exploit works, are you sure that you did disable the CSRF token in your website?

Using the same method he can add himself as admin, delete users, add forum posts, delete forum posts, change settings, inject javascript to steal cookies, that is just a basic exploit, do not expect a full functional exploit in here.

That's why nobody should remove the CSRF token.

In some local servers the method UTIL_String->getRandomString gives the same string several times and that's why you see this CRSF token error, this file needs to be edited to fix it, I have never seen this problem in a production server. This may be your case.

Senior Developer.

CSRF depends on you being logged in as admin, so when you click the link naturally, it should open in your default  browser which should already have an active session to your site.

That is how CSRF works, but since you had an idea beforehand, you separated the browser and it doesn't work like that. 

They are relayed or bounced through your browser to the target website to piggy back on your active session, so naturally the victim has to have an active session to the target website in the browser that opens the link...

Think not like a developer or security pro but just a normal oxwall admin who might click an unsuspecting link trying to help someone, maybe even one of your own users who can see when you are online (active session, higher success probability.)

I use several computers, several browsers and several users simultaneously because I am aware of what users write in the chat rooms of my commercial website, and it is highly probable that when I clicked the link the CSRF outside of another user, or the CSRF of the admin was on another team, or ... I don't even know.

I have to try it more calmly, weekends are crazy on my website.

I suppose that the ideal way to sneak the link is to send it to the admin by internal email, so I'm sure the admin is logged in when he reads it, and it's the same browser / computer and everything.

I think it's okay for us to check these security things

We need to secure Oxwall as well as we possibly can.

I'm willing to help by the way! :-)