88
The last dash basically protects the trailing space. If you exploit SQL injection in a browser (e.g. via the URL), some browsers remove trailing space characters. Some prominent SQL flavors explicitly require the Space after Dash-Dash to treat the sequence as the start of a comment, so attackers often add a character after the Space to protect it against ...
48
Using non-standard paths for your WordPress login and admin pages would stop automated brute-force attacks scanning for every example.com/wp-login.php, but the practice you describe is just messing around with the attackers and doesn't really do any good nor harm.
Best way to stop the bots is to use strong passwords and Fail2Ban.
A fake wp-login & wp-...
19
It is not an effective way to stop bots. Bots will register that link as providing a response. They will not "give up" because the end result is not what they expected.
It would be more effective to have have a fake login page and block any IP that attempts to log in.
18
Sending sensitive data in a post request is a common approach. Take any form-based authentication mechanism for example. A user enters his credentials in the web-frontend (browser) and a post request is sent to the web-server in the backend. If this backend actually is a classical web application or an Azure function doesn't matter.
It is important though ...
11
By adding fake login pages you would actually be turning your website into a honeypot, which would attract more bots and actually increase your server load. I don't know why StackExchange redirects to YouTube, maybe it's just for fun (it looks like they redirect you to random 10-hour videos, including a 10-hour trololol song). If you want to avoid attracting ...
4
Is there any way to access the contents of a cross domain iframe
Not programmatically (see below for another approach), as the same origin policy will not allow this. If it did, that would be cause for alarm, not just in your situation. An attacker could steal CSRF tokens and perform arbitrary actions, read all data the user has access to, etc.
I found ...
3
Bandwidth? Preventing legitimate users? Unlikely!
This is not a denial-of-service (DoS) attack in nature.
These are brute-force login attempts. They are short POST and GET requests with short replies – not downloading huge files. Replying 200 OK vs. 403 Forbidden or 404 Not Found consumes relatively same amount of bandwidth, which is next to nothing. ...
3
I don't see how. When creating an iframe, a GET request is sent to the iframes src, but not to the server hosting the iframe.
So deskofhelp[.]com will likely have tupperware.com in its logs as referer header, but not the other way around.
Cross-origin frames can be logged by using a frame-src CSP directive combined with report-uri (or the newer report-to), ...
2
You only give a limited amount of information about the system, so I can only give a broad answer. A good source for orientation is the current ASVS (Version 4.0.1). In chapter "V12: File and Resources Verification Requirements" we can find requirements for file uploads that point us in the right direction. I've selected some of those requirements and added ...
2
I take it you have a situation like this:
<h1><!-- Data is inserted here. --></h1>
That is what OWASP calls inserting "into HTML element content" in their cheat sheet. To get anything done in thet context you will need to open a tag, so you will need a <. Without that, you are toast at that specific location.
The protection they are ...
2
You might want to think about running the web server with the normal level of permissions, then setting up the application to store the commands in a text file on the server. Then, a script running on the server with root permissions (either a cron job, or a daemon) can read the commands from the text file and execute them.
This way, you'll achieve your ...
2
In order for cookies to be sent with cross-site requests, .withCredentials must be set to True in the cross-site request. See https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS for more info (scroll down to the section 'Requests with credentials').
2
Hacking your server and profiting from it is the cybercriminal's job. Their "job" is unregulated, risky, unstable, without any guarantees, highly competitive, in an environment where they need to be faster than their opponents (not only other criminals, but also sysadmins, antivirus vendors, etc.) and they need to exploit every opportunity they have before ...
2
No.
If a bot never probed your website before, it doesn't know that this specific page does not exist. It must make a request to find out. If it gets a 404, it can either remember this fact and avoid requesting this site again, or it simply forgets about it and might request the same resource in vain again later. The latter approach is probably used more ...
1
This is a tough one! Let's analyze the scenario in regards to the potential chances and risks. This might give you a foundation to make an educated choice.
Scenario: We live in the year 2020. People are able to make a good living off working as a cyber security professional. From consulting over secure development to bug bounty hunting - there is a niche ...
1
It obviously doesn't work for bots, but based on looking at logs I've found that bored script kiddies are effectively discouraged by redirecting the query to https://www.fbi.gov/investigate/cyber
For the bots, a lot depends on whether or not you have a good host or control over your own hosting environment. There are Apache ModSecurity rules that will block ...
1
Cookies with a MUST of "httponly" and "secure" attributes are the only secure way forward. This is because in a scenario of a XSS (Cross Site Scripting) attack LocalStorage or the DOM data can be easily read by the attacker.
If you define a cookie with httponly tag Javascript can't access that value, preventing XSS attacks.
https://developer.mozilla.org/en-...
1
This is not something we can answer here, there are way too many possibilities.
For instance: you assume he didn't get access to the server because it is 'pretty secure', how do you know?
You also state that 3306 is closed, but phpMyAdmin is running. So an attacker might enter there.
SQL injection is always a possibility, why do you think it is not?
It ...
1
It seems based on the details provided, that the endpoint itself is not authenticated and the connection string is being sent in HTTP body. If this is indeed the case then:
From transport point of view, sending sensitive data in HTTP body might be fine as long as your connection is protected by HTTPS with TLSv1.2 or higher. Make sure clients are not ...
Only top voted, non community-wiki answers of a minimum length are eligible
