I'm running Keycloak 15.0.2 that have a XSS security vulnerability https://bugzilla.redhat.com/show_bug.cgi?id=2013577 Reflected XSS on clients-registrations endpoint. It's fixed in 18.0.0, but I cannot upgrade to 18.0.0 (that would be the best I know). So I'm looking at workarounds like disabeling the user account management screen and block unneeded urls. But how can I do that?
Related
I would like to know if the security vulnerabilities for web based applications such as the ones due to poor input validation such as
SQL injection
XML injection
XSS
CSRF
Click Jacking (Frame bursting)
Since the mobile app runs in its own sandbox environment, i would have thought that the browser specific vulnerabilities would not be applicable.
OWASP does not list out these as part of their top 10 list and I wanted to understand if there is a scenario where these can pose a issue for mobile apps
Most of the vulns described in the OWASP top 10 are attacks against the server. E.g SQL injection, XML injection, Java deserialization, CSRF and others.
Thus it doesn't matter if the client is a browser or a mobile App. The attacker can craft their requests with any tool they want.
There are specific vulns related to mobile application on the client side. These are described in the Owasp mobile app top 10
I would like to know if intercepting and modifying requests using Burpsuite before reaching server is considered as vulnerability.
In our web based and mobile applications, adequate security measures are in place to avoid replay attack and data integrity etc.,
Now the same is being evaluated by one of the application security teams, they use burpsuite to intercept the request payload and have raised few security vulnerabilities which aren't reproducible without using Burpsuite.
So using such tools is still a valid case and considered to be vulnerable?
is moodle free from cross site scripting (xss) vulnerability? if yes please let me know how it is fixed. If not what will be the solution?
No CMS is completely secure. Moodle is no exception and there are a few known areas where XSS vulnerabilities are present - those vary depending on version and depending on the level of access available to the attacker.
There is no umbrella fix for XSS vulnerabilities. I would advise revising the question.
Moodle takes security very seriously and any report about XSS vulnerability is addressed very quickly. Security fixes are released only in the minor versions (every two months), so if you upgrade yours site regularly you can be sure that your site is not vulnerable.
See also https://docs.moodle.org/dev/Moodle_security_procedures
Do not forget that some capabilities are marked as having XSS risk, by default students do not have any of these capabilities but teachers do. There is a security report about XSS trusted users. You have to trust your teachers in moodle
We have developed an app in Salesforce which uses the DocuSign web service API (https://demo.docusign.net/api/3.0/dsapi.asmx for development and https://www.docusign.net/api/3.0/dsapi.asmx for production). We found few vulnerabilities when we did the security scanning on both the APIs. We used ZAP tool for security scanning and it revealed the below vulnerabilities:
X-Frame-Options Header Not Set
Incomplete or No Cache-control and Pragma HTTP Header Set
Web Browser XSS Protection Not Enabled
X-Content-Type-Options Header Missing
Can these issues be fixed on the web services or Is there any document that proves that these are false positive?
Thanks
Zap, like all automated scanners, are very good at finding common oversights and comparing applications with best practices. Unfortunately, they do often fail to consider the larger scenario at hand. Setting the correct x-headers for the right scenarios is an important protection against common attacks like click-jacking and XSS in client-server web flows, as they help inform the user's browser which actions should be permitted or not. Those attacks are not relevant in a server to server API flow, however, so these should be considered false positives. Thank you for bringing these to our attention, however, DocuSign is continuously investing in our platform's security and we appreciate the scrutiny.
Opencart used to have a CSRF vulnerability. This has lately been fixed apparently. Even so if there are still security issues does it even matter if Paypal is the only payment gateway method used (i.e does Paypal's own security override opencart's or any other e-commerce shopping cart for that matter?).
CSRF was fixed over a year ago in OpenCart (version 1.4.8 or 1.4.8b I think it was) - it's only on the admin side that this was ever done, so it has no effect on your payment gateway etc
You should use an SSL certificate for any site you intend to take people's personal information, regardless of how they make payments. That said, paypal (standard) will use all of paypals security, and as such you don't need to worry about that side of things, as any liability will lay with them should any payment details be lost/stolen during that process.
That said, I've never had an issue with any of my sites or client sites where any user information has been stolen as a result of bad paypal security, not have I actually heard anyone has to be honest, so you're in good hands if you use them