New answers tagged web-application
0
It looks like some malicious actors automated attack tool tried to exploit tomcat. It's not guaranteed that the downtime is associated with this attack, because your Tomcat instance probably receives attacks like these a lot. I would suggest looking at other stuff which could have caused the downtime.
2
There are tools like Fail2Ban that temporarily restrict access from IPs that have tried for non-existing files in a short time range too often (it is configurable what "too often" means exactly). This will reduce the scanning traffic on your site, but as @fleitner already wrote, you cannot exclude it completely.
3
That is just normal background traffic. All domains are crawled all the time in order to find common vulnerabilities:
Unsecured or default passworded admin areas (like the wp-admins.php in your listing)
Files containing credentials (config.php)
Files or directories that are publicly available but not linked on the page (resulting in some people thinking ...
1
You can have something like a JWT token, where the user (front-end) will know, but can't read it. Then, for each request you send the JWT token and your back-end will know how to decrypt and validate if the user can perform or not this action.
0
Adding on Anders answer, consider using "Invisible Captcha" on the login endpoint, Google is doing a great job detecting/stopping bots.
Please note this is not a solution just a way to slow down whoever trying to scrape your website.
0
The user-agent HTTP header is sent inside the request and the request is TLS encrypted, so no way to modify the request directly.
There is one way an attacker could potentially pull this off.
Let's take an domain example.com
1. A user connects to http://example.com which does a 301 forward to https://example.com for all requests
2. The attacker intercepts ...
0
As already said, the idea behind "don't trust the client" is that the client can be sending anything. It is at the mercy of the user, who could be an attacker, and therefore must be considered a potential attacker itself.
This is paramount in web development, but applies almost equally well to any other client/server architecture. (It's just easier to ...
3
Adding encryption on its database per-field or per-group-Of-field basis seems like the best trade off provided that an index field(s) is also created alongside with each field being encrypted.
You would solve several problems at once.
Searching index would be just as fast
Not all fields need to be encrypted
Overhead of encryption is kept to a minimal ...
4
"Don't trust the client" means that whatever input comes from the client might have been sent maliciously, because you can't control it. So, for example, this means that authentication and authorization must be checked and enforced server-side. If you let the client validate anything and then tell you "ok", a malicious user could just skip the validation and ...
27
Letting your database handle the encryption/decryption is probably for the best:
You don't need to write any encryption/decryption code and risk breaking your own security by accident. This also means, as Guntram Blohm pointed out, you won't have to prove your own security to be secure, if it comes down to it. And proving your custom software secure is as ...
2
Well, for starters, a token can be expired in a relatively short period of time, forcing a user to re-authenticate. A password is generally has a much longer life. Thus, if a token is stolen by an attacker it is useful for a relatively short period of time (this is one reason that when you have to change a password a good system will force you to enter the ...
-2
Can Access Control Allow Origin on Same-Origin will help out?
Access-Control-Allow-Origin defaults to not being accessable by another origin. So if this header is not set, you're good.
Or maybe an X-Requested-With header?
Yes this can help prevent AJAX request. I recommend this CheatSheet for more in-depth information regarding this topic.
If there ...
3
If some server backend for the app is sending the requests
As I understand it, the requests that fetch data from your website are comming from a server that works as a backend for the offending Android app. You have a number of possibilities:
Block the IP of the server. This may end up being a cat and mouse game if they change the IP, so not the greatest ...
0
With JSP as far as I could analyse it, it is only possible to run a JSP on the attacker server, not on the victim server. (If somebody can disagree, I would be very happy about an example with code).
So in your case localhost:8082 must be the attacker server. To run the code the attacker server must also be a web container e.g. Tomcat in which rfi.jsp is ...
2
How do you track and monitor vulnerabilities in open source software?
The same way it's monitored in closed source software. Vulnerabilities are reported and updated in subsequent releases. Generally this cycle is even faster with OSS.
What steps do you take to ensure that the open source software is risk free?
The same steps that are taken with closed ...
1
Focus on the first question:
How do you track and monitor vulnerabilities in open source software?
Things you can (and should do):
Use distributions repositories. Major distributions such as Debian, Ubuntu, RHEL, etc. are quite good at patching in a timely manner. Staying up to date with these solves many issues.
Monitor relevant security related ...
5
You are correct this implementation of constant-time string comparison will leak information about the length of some string that is being compared against an attacker controlled string.
However, if this is checking strings for authentication purposes, you never should be comparing raw strings. You would first hash (preferably with a salted key-...
0
If you don't need CSRF protection because the request is idempotent then you don't need a CSRF token.
Reading request.GET in the view, with or without a form, does not affect security.
Using function based views or class based views does not affect security.
I believe simplicity is good, so I would recommend to always use function based views because they ...
7
The greatest risk is if the site logs login attempts based on the username that a user enters, rather than the account. Your password will then be displayed in cleartext in the logs, which may be leaked at some future time.
In most cases, nothing risky will happen. The site already has access to your cleartext password while you're logging on, whether ...
4
Pentesting isn't about knowing RFCs by heart. If there is a specific information you need for a specific test, you can always just look it up.
It's much better to have broad fundamental knowledge, and know where to find specifics, rather than to attempt to cram as much specific knowledge into your head as you can.
The question "Which books should I read ...
0
Path Traversal (AKA dot-dot-slash): This attack, also known as the dot-dot-slash attack (../), is usually performed by means of those characters that allow us to move up in the directory tree.
By prefacing the sequence with ../ it may be possible to access directories that are hierarchically higher than the one from which we are picking the file.
File ...
0
Do not use user input
(because you camnot trust it)
This answer extends the accepted with what looks to me a significant simplification.
Now, from your description and from my best understanding, you have said that you want to prevent Sales Agent A (namely 12345) to peek into Sales Agent B's (namely 54321) data.
Simply, kill the agentId parameter from ...
0
Your point makes sense.
The OAuth2.0 RFC (section 1.3.2) explains this :
Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application),
since it reduces the number of round trips required to obtain an
access token.
But the industry best practice has changed. The OAuth 2.0 ...
0
Unfortunately what you are trying to do is effectively impossible because HTTP simply was not intended for this use case. I think there are a few misunderstandings that are confusing the issue for you. Running through things:
There is nothing special about browsers. Browsers are just a fancy HTTP client that can send HTTP requests to an HTTP server. ...
1
To answer your question: It's really not a good idea to let any less-than-fully-trusted process self-modify, and that's especially true for frequently-launched and highly-exposed programs like web servers. The principle of least privilege applies really strongly here, and web servers do not need the ability to self-modify.
Fortunately, there are solutions. ...
2
Some applications work around this by using ftp. They login to localhost with a given username. That’s more portable on some Webhosters that sudo.
It is a good practice if the web server cannot modify code, because this is a very common way for permanent infection. On the other hand for convenience it’s often done. If your scripts are secure (and you don’t ...
0
This is a really big question, and one that might benefit from being broken down a bit. I'll start with question #0, though.
Is there a standard protocol? Several. It depends on exactly how you want to do this. Consider this extremely simple approach:
Cross-Origin Resource Sharing (CORS): The user logs into MS, and MS sends an authenticated CORS request to ...
Top 50 recent answers are included
