<div dir="ltr">When scanning our site using the OWASP scan tool Zed Attack Proxy (<a href="https://owasp.org/www-project-zap/">https://owasp.org/www-project-zap/</a>) we are receiving a couple of findings.  Has anyone scanned their Shibboleth enabled site and seen anything similar?  Any idea how we mitigate these?  Are they real issues?<div><br></div><div>-- Buffer Overflow --</div><div><b>Description:</b>  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.</div><div>URL:         <a href="https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST">https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST</a></div><div>Method:  POST</div><div><b>Parameter:</b>  RelayState</div><div><b>Attack: </b> POST <a href="https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST">https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST</a> HTTP/1.1 Connection: keep-alive Content-Length: 8473 Cache-Control: max-age=0 sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99" sec-ch-ua-mobile: ?0 Upgrade-Insecure-Requests: 1 Origin: <a href="https://ourshibbolethpage.net">https://ourshibbolethpage.net</a> 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/88.0.4324.104 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: cross-site Sec-Fetch-Mode: navigate Sec-Fetch-Dest: document Referer: <a href="https://ourshibbolethpage.net/">https://ourshibbolethpage.net/</a> Accept-Language: en-US,en;q=0.9 Cookie: _opensaml_req_ss%3Amem%3A19fe48f3fed957261b69a106bd02970dd9ca03530b060b95f75c5b4f60b3f2a0=_db09ec53e9da62cd59684d6214755482; ASP.NET_SessionId=uygamidw0j3xskjc0x24hiuw Host: <a href="http://ourwebsiteaddress.edu">ourwebsiteaddress.edu</a></div><div><b>Solution:</b>  Rewrite the background program using proper return length checking. This will require a recompile of the background executable.</div><div><b>Other information: </b> Potential Buffer Overflow. The script closed the connection and threw a 500 Internal Server Error<br></div><div><br></div><div>-- SQL Injection -- </div><div><b>Description:  </b>SQL injection may be possible.</div><div><b>URL: </b> <a href="https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST">https://ourwebsiteaddress.com/Shibboleth.sso/SAML2/POST</a></div><div><b>Method: </b> POST</div><div><b>Parameter:</b>  RelayState</div><div><b>Attack:</b>        ss:mem:f7314703afcd7f67597beb91f55dc7dc7a5904b0d9bc0236bbb6abb209e25771' OR '1'='1' --</div><div><b>Solution:</b>  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.</div><div><b>Other Information: </b> The page results were successfully manipulated using the boolean conditions[ss:mem:f7314703afcd7f67597beb91f55dc7dc7a5904b0d9bc0236bbb6abb209e25771' AND '1'='1' -- ] and [ss:mem:f7314703afcd7f67597beb91f55dc7dc7a5904b0d9bc0236bbb6abb209e25771' OR '1'='1' -- ]The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison Data was NOT returned for the original parameter. The vulnerability was detected by successfully retrieving more data than originally returned, by manipulating the parameter</div></div>