Raid
Hazard to Everyone
Posts: 201
Registered: 14-11-2022
Location: N/A
Member Is Offline
Mood: School
|
|
Website STILL vulnerable to XSS and possibly SQLi
Hi Admins, I just wanted to let you know for the second time that your website is still vulnerable to XSS. I would really hate to have some bad actor
come across this website while doing some google dorking and think that its a great place to steal peoples data. I see that someone has fixed the
search bar XSS exploit but that can easily be bypassed with a simple encrypted function that makes it harder to detect XSS, there is a whole list of
these on portswigger.net under their XSS section. I also believe that they have a section that tells you how to protect from this type of attack.
Currently, your website is vulnerable to POST and GET XSS attacks.
It could also be vulnerable to a SQLi attack with a injectable POST/GET header.
Might want to check up on that.
There are multiple free websites that allow you to check for basic vulnerability's on your website and I will link one at the bottom that can show you
some vulnerability's without having to make an account.
Mind you that there are much better ones but you may have to pay.
Also, you website is vulnerable to EVERY type of DDoS attack there is, so that's fun.
I would recommend getting a firewall service like cloudflare (best).
They also give out a free DNS/Proxy service that can protect from light DDoS attacks and phishing.
The IP's are as follows
1.1.1.1
1.0.0.1 (Back up)
They are great and free, they do offer enterprise ones that are even faster on their website. (cloudflare.com)
I'm guessing that you already have a web application firewall (WAF) that "should" protect cookies but knowing that this website is way out of date I
would assume that there are many exploits for bypassing this.
There are some repositories on GitHub that provide free protection for users
cookies (eg. document.cookies).
Another this that's kind of a must have is something to block JavaScript from being used on the website as that would fix people from tampering with
things and possibly grabbing user cookies.
Thanks for your time 
Please get a better firewall.
|
|
|
Raid
Hazard to Everyone
Posts: 201
Registered: 14-11-2022
Location: N/A
Member Is Offline
Mood: School
|
|
Here are some more of the HTTP/S configuration vulnerability's
CVE-2023-25690
Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack. Configurations are affected
when mod_proxy is enabled along with some form of RewriteRule or ProxyPassMatch in which a non-specific pattern matches some portion of the
user-supplied request-target (URL) data and is then re-inserted into the proxied request-target using variable substitution. For example, something
like: RewriteEngine on RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P] ProxyPassReverse /here/ http://example.com:8080/ Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to
existing origin servers, and cache poisoning. Users are recommended to update to at least version 2.4.56 of Apache HTTP Server.
CVE-2022-36760
Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to
smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior
versions.
CVE-2017-3167
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication
phase may lead to authentication requirements being bypassed.
CVE-2017-3169
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_ssl may dereference a NULL pointer when third-party modules call
ap_hook_process_connection() during an HTTP request to an HTTPS port.
CVE-2017-7679
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, mod_mime can read one byte past the end of a buffer when sending a malicious Content-Type
response header.
|
|
|
|
![[*]](images/xpblue/default_icon.gif){kind=icon}
