The following warnings occurred:
Warning [2] Undefined variable $unreadreports - Line: 26 - File: global.php(961) : eval()'d code PHP 8.2.25 (Linux)
File Line Function
/global.php(961) : eval()'d code 26 errorHandler->error
/global.php 961 eval
/showthread.php 28 require_once





× This forum is read only. As of July 23, 2019, the UserSpice forums have been closed. To receive support, please join our Discord by clicking here. Thank you!

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
UserSpice and Security
#1
Hello Guys (and girls),

I allow myself to come back to you about this cms and security. Indeed, I could see a security audit report calling to avoid leakage of information in the source code. They explain that the source code contains information to know the CMS used and thus to better target potential attacks.

While searching a little on the net, some recommend to go through an obfuscator, and others do not advise.

So I come to you to have your opinion on this? Someone would have had the same problem?

Thank you in advance Smile
  Reply
#2
My belief is that open source code allows us to find and fix bugs more quickly and makes code more secure.
  Reply
#3
(07-03-2019, 10:34 AM)mudmin Wrote: My belief is that open source code allows us to find and fix bugs more quickly and makes code more secure.

Hi,
I understand your opinion.
I am of the same opinion as regards the returns of developers / users and the increasing security thanks to that.

This is a constraint I have on a project, where the client has passed a security audit and the result indicates a "leak of information" about the CMS used in the source code.

I guess it's having comments that clearly indicate the CMS in particular.
  Reply
#4
The CMS you are using is not based on user spice right? we have passed all of the security audits that we have had performed.
  Reply
#5
(07-03-2019, 02:19 PM)mudmin Wrote: The CMS you are using is not based on user spice right? we have passed all of the security audits that we have had performed.

This is the message of the security audit :

"Remove information leaks in the application's source code.
We have highlighted technical information in the source code of the application to identify the CMS used by the application.
This information makes it possible to target attacks on this CMS and potentially benefit from a referenced vulnerability on the internet.
We recommend that you delete any information that identifies the use of the UserSpice CMS"

In fact, the application is UserSpice, not a CMS using UserSpice.
  Reply
#6
I think what they are saying is that in their idea it is a bad idea to let people know what framework you are using. I feel like this is kind of stupid. Just because you know a site is running WordPress doesn't mean that you can hack it. That said, you can go in usersc/includes/ and there are head tags and maybe security headers files where you can hide all the metadata that would suggest Userspice.
  Reply
#7
(07-03-2019, 03:32 PM)mudmin Wrote: I think what they are saying is that in their idea it is a bad idea to let people know what framework you are using. I feel like this is kind of stupid. Just because you know a site is running WordPress doesn't mean that you can hack it.  That said, you can go in usersc/includes/ and there are head tags and maybe security headers files where you can hide all the metadata that would suggest Userspice.

Thank you for your answer, I will look at this side.
And I agree with you that you find that stupid, I think so too.
Knowing that if we update regularly, each potential security hole is often corrected quickly.
  Reply
#8
I will say from the very beginning one of my very first goals was to never really show user spice to the front end user. So for the most part, the only thing you have to do are change things that are easily changeable. That is pretty much, the logo, the favicon, The copyright message in the metadata.
  Reply
#9
(07-04-2019, 10:51 AM)mudmin Wrote: I will say from the very beginning one of my very first goals was to never really show user spice to the front end user. So for the most part, the only thing you have to do are change things that are easily changeable. That is pretty much, the logo, the favicon, The copyright message in the metadata.

I will follow your advice and make these changes. I'll see if that's enough for the company that did the security audit.
I thank you for the attention you paid me.
  Reply
#10
Absolutely. If there is anything else that we can do, please let me know.
  Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)