• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

Vulnerability's [False positives]

rickblack28

Chevereto Noob
XSS/Cross Site Scripting, RISK: LOW (These XSS won't work in current new browsers)
1) in all of /
2) via ?urls string
3) Also the underscore'd subject's

SPDY Heap B-Overflow, RISK: VERY HIGH! .. you'r database will get compromised soon.
(Those who can exploit this will have the ability to execute bash/cmd codes)
(CVE-2014-0133), this does not apply for people with the latest version of nginx.

==============
Web Application error's, RISK: LOW ( its just some information disclosure )
1) at Album
2) at Explore

Fatal error [400]: Limit integrity violation
Triggered in /app/lib/classes/class.listing.php at line 175

Stack trace:
#0 /app/routes/route.album.php(72): CHV\Listing->exec()
#1 /lib/G/classes/class.handler.php(206): G\Handler->{closure}(G\Handler)
#2 /lib/G/classes/class.handler.php(110): G\Handler->processRequest()
#3 /app/loader.php(304): G\Handler->__construct(Array)
#4 /index.php(20): include_once('/app/loader.php')


As the error above says... something goes wrong at line 175 http://demo.chevereto.com/app/lib/classes/class.listing.php
==============

And Damn! you have a problem with putting some protection on CSRF?
1) /
2) /account/password-forgot
3) /login
4) /najonila
5) /page/contact
6) /page/privacy
7) /page/tos
8) /signup

... and text is sent in clear text, RISK: MEDIUM
this means that MITM (man in the middle) Attack's can see Login Credentials in clear text.
You should send password and username encrypted in post request :)
make your script encrypt the strings (Just SSL Wont stop Form Grabbers)

Brute force is also possible, RISK: Very Low
 
And that error, "Limit integrity violation" is set in the code. So the code is correctly handling your attempt to break it, and returning an error message. You've not actually broken anything.

Not really a security vulnerability, because you can't do anything with any of the stuff you've just done.
 
... and text is sent in clear text, RISK: MEDIUM
this means that MITM (man in the middle) Attack's can see Login Credentials in clear text.
You should send password and username encrypted in post request :)
make your script encrypt the strings (Just SSL Wont stop Form Grabbers)

Brute force is also possible, RISK: Very Low

You'd need to install and SSL certificated for this. It's not a code issue. Why would he put an SSL cert on the demo site? If you want to encrypt that data, install an SSL cert on your own site.
 
We do CSRF protection in every form request, even in the ajax requests. Did you really dig in the code?

He hasn't dug into the code. He's run a web vulnerability scanner, it's a scanner that points out common mistakes. It will test XSS attacks and CSRF attacks, but it doesn't actually know if they are successful. If it causes an error, like the one he mentioned in "http://demo.chevereto.com/app/lib/classes/class.listing.php", then it assumes that the attack was successful and "logs" it as a threat.
 
For example, a web vulnerability scanner recgonises this: /search/images/?q=1%26n987806%3dv917035 - as a Parameter Pollution attack, when in reality, it's not. But the scanner will tell you it is.
 
You'd need to install and SSL certificated for this. It's not a code issue. Why would he put an SSL cert on the demo site? If you want to encrypt that data, install an SSL cert on your own site.

He has SSL till 2022 , thats very good!
And SSL wont stop MITM
if you want i can video tape how i intercept it?

you can simple use sslstrip with ettercap and it will do the trick, you really must send the user+pass in an encrypted string like paypal does.

And ddotgrass, besides the obvious vulnerability scan i am also digging in the code but you should know that i cant read your PHP files from here, i am going to buy your script for this.

no need to get so upset, i am trying to help.
 
He has SSL till 2022 , thats very good!
And SSL wont stop MITM
if you want i can video tape how i intercept it?

you can simple use sslstrip with ettercap and it will do the trick, you really must send the user+pass in an encrypted string like paypal does.

And ddotgrass, besides the obvious vulnerability scan i am also digging in the code.
no need to get so upset, i am trying to help.

I'm not upset, I'm just saying that your "tests" are irrelevant and are being handled properly. It just looks like you're a script kiddy, I see this all the time, especially as a lot of my work involves penetration testing for bigger companies.

Test the code all you want, it doesn't bother me. I just think, that, if you run a vulnerability scanner, you should test the errors are actually true. Whereas it's clear you haven't and none of your errors you've found actually exist, lol.
 
As i said before, i cannot check if its true without access to the files.
for this i will have to purchase the script.

You can check it's true. If the vulnerability scanner tells you there's an error, go and check it yourself. It's just a vulnerability scanner, it is NOT a reliable source of information regarding threats, as it gets it wrong A LOT. Test the errors for yourself, I managed just fine.

Parameter pollution => false
CSRF => false
XSS => false

I could explain to you how vulnerability scanners work, if that would help you?

Also, you referenced above buying "my" script. It's not mine. I don't have any development access to Chevereto other than my own files. I'm just commenting because penetration testing is my expertise, and I wanted to inform you that your scan was incorrect and unreliable. That's all
 
Back
Top