Shibboleth Scan Findings from OWASP Scan Tool

[Bowers, Peter S]

We continue to see scan findings come back from our security department regarding Shibboleth.  The scan results included the results below.  We are currently on Shibboleth SP 3.2.3.1 release: https://shibboleth.net/downloads/service-provider/latest/ . Has anyone else seen these results?

Medium (Medium) Buffer Overflow
Description

Buffer overflow errors are characterized by the overwriting of memory spaces of the background web process, which should have never been modified intentionally or unintentionally. Overwriting values of the IP (Instruction Pointer), BP (Base Pointer) and other registers causes exceptions, segmentation faults, and other process errors to occur. Usually these errors end execution of the application in an unexpected way.

URL     https://profiles.umassmed.edu/Shibboleth.sso/SAML2/POST
Method  POST
Parameter       SAMLResponse
Attack  POST https://profiles.umassmed.edu/Shibboleth.sso/SAML2/POST HTTP/1.1 Connection: keep-alive Content-Length: 2200 Cache-Control: max-age=0 sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="96", "Google Chrome";v="96" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Windows" Upgrade-Insecure-Requests: 1 Origin: https://sm-tst11.ucollaborate.net Content-Type: application/x-www-form-urlencoded User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Accept:


High (Medium)   SQL Injection
Description

SQL injection may be possible.

URL     https://profiles.umassmed.edu/Shibboleth.sso/SAML2/POST
Method  POST
Parameter       RelayState
Attack  ss:mem:714a0f4dcc377cbf4da5711788e1a5fafbaf4210e55721ab1ed425e639022676 AND 1=1 --
Instances       1
Solution

Do not trust client side input, even if there is client side validation in place.

In general, type check all data on the server side.

If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'

If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.

If database Stored Procedures can be used, use them.

Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!

Do not create dynamic SQL queries using simple string concatenation.


Pete Bowers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20211124/360526d5/attachment.htm>