How do I resolve the following security issues after pentest.

[phamxuantung]

Hello,

We just got our application pentest on Splunk, and there are many issues that pop up. These issues are:

1. SQL Injection ( 11299)

2. Insecure Transport ( 4722 )

3. Credential Management: Sensitive Information Disclosure ( 10551)

4. Often Misused: Login ( 10595 )

5. Password Management: Weak Password Policy ( 11496 )

6. Often Misused: HTTP Method Override ( 11534 )

7. Cookie Security: Persistent Cookie ( 4728 )

8. Privacy Violation: HTTP GET ( 10965 )

9. HTML5: Overly Permissive Message Posting Policy ( 11347 )

10. HTTP Verb Tampering ( 11501 )

11. Path Manipulation: Special Characters ( 11699 )

3, 4, 5 and 7 I can manage but the others I don't know how to fix, because I'm only familiar with Splunk Web interface.

I wanted to ask:

1. If I'm enable SSL and switch my Splunk web url from http -> https, can we fix HTTP relate issues which is 6, 8 10.

2. How can I fix other issues, they told us to screenshot evidences as well if we can't fix them, where do I look for it?

Thank you in advance.

[PickleRick]

TLS should be on in production environment anyway so it's a good start. And of course you need to use external CA, not the default certificates which splunk generates from the built-in CA.

The rest of those findings is a bit unclear without more precise information. For SQL Injection, for example, you must have a particular URL which results in SQL Execution. Since Splunk on its own doesn't use SQL, this finding is highly questionable - maybe you indeed have some app installed on your splunk server that is vulnerable or maybe it's some other system component, not the splunk server itself. Or maybe it's a false positive. Were you provided with more details about those findings or just given a simple list and "have fun with it"? If it's the latter case, it seems like a somewhat unprofessionally performed pentest.

[phamxuantung]

It's gonna be a lengthy report so please bear with me.
We have a test server and a production server, and in our production server we have our own SSL certificate, and LDAP authenticate so some issues can be resolve. The pentest was perform on the test server with the pretense that test server and production server should be 1-1 (which is ridiculous because our test server was severely lack in resource and it is a testing ground for development)

[PickleRick]

I'm not sure you should be posting this report here. This is after all a relatively sensitive information regarding your internal infrastructure. Not to mention any NDA-s you may have with the pentesters (however lazily this pentest was performed). You might want to delete the post.

Anyway.

You have some report from an automated tool. If you paid only for a tool run, that's what you should get. If you paid for a "full" pentest, you should get a report written by human, outlining the vulnerabilities, explaining them and suggesting remediations. At least that's how it went with all the pentests I've seen. The pentest crew should also verify, at least the most sever ones, for being false positives.

That's why you hire a pentester with experience instead of just buying a tool.

[phamxuantung]

You're right, I shouldn't upload that here, deleted that.
But I still want to figure out what the deal with SQL Injection issue

And how to execute their recommend fix (although automated)

[PickleRick]

OK. Firstly - I think it's a false positive. As I said - splunk on its own doesn't use SQL at all. The only SQL thing regarding Splunk I know is the use of DBConnect app but this "finding" doesn't seem to have anything to do with that.

Secondly - Splunk doesn't allow you to customize HTTP operations on such low level. Short of putting a reverse-proxy in front of it and forcing all traffic to go through that proxy there is no way to configure this on Splunk alone.