The Stack Overflow podcast is back! Listen to an interview with our new CEO.
8

If you can fake the price this way then this is basically due to improper validation of user input. It does not matter if the fake price comes because you've used another API endpoint (spoofing name resolution with manipulating hosts file or DNS) or if you've edited the page in the browser or if you've changed what got submitted to the server by intercepting ...


8

Responsible disclosure, which most people on this site seem to endorse (including me), and is regarded as the most ethical way to notify a company of a vulnerability, is precisely what your comment says you won't do: Saying that you will tell the public. With responsible disclosure, you're just giving them a chance to plug the hole and manage PR first, by ...


4

The short answer is: Yes, but only if you need to be that secure. The side-channel vulnerabilities are a variety of ways that software can determine what data exists in places that it should not have access to---either by reading it directly or by inference. There are a variety of approaches to prevent this, but the nature of the barrier is determined by ...


3

The HTTP method does not matter for Cross Site Scripting attacks (XSS). It is even possible to get XSS trough the HTTP TRACE method. Is it possible to have reflective XSS through POST requests? Most definitely!


3

Not any sort of vulnerability; simply a usability issue that might affect users visiting the site from a malformed URL. It is not an easy way to perform a DOS attack, because there is no evidence that this is taking any more resources on the server than hitting non-redirecting set of pages, or preventing other users from accessing different pages. You can ...


2

Yes, "2038 bug" might be a vulnerability, but it fully depends on how the application you're attacking is coded. Say, you have a web application that does this: if ($todayTimestamp > $user['rightExpiresTimestamp']) { did('Not allowed'); } So the user was granted access until, say, 2018 so it's now expired, because today's timestamp is about ...


2

Prototype pollution can be exploited at the front end. Payloads can be sent in similar fashion to reflected and stored XSS, and affect the behaviour of the front end for the victim recieving them. So this is a real issue that you should deal with. The most famous example of prototype pollution vulnerabilities is probably from jQuery - a client side library. ...


2

There are two quick observation: Using eval is very dangerous and your variable ${command} is not efficiently sanitized. (They could contain backticks, period, control chars, etc) Using bash for sensible operation is not recommended as they suffer from a lot of vulnerabilities. I recommend using poor shell (like dash), for critical scripts. (Or more evolved ...


1

As I assume you want to monitoring tool beside then WAF, there is two well known tools for this purpose: ManageEngine event log analyzer Nagios IIS log monitoring


1

Sounds like you need to do a bit more to reduce your attack surface. While you have already done a lot of things to improve your situation which is good, unfortunately you have absolutely no control of your physical network which is generally the source of most hacking attempts. This is compounded even further by the fact that that it is a shared network and ...


1

As a general rule, every security application that performs monitoring or blocking will have a place for you to review any alerts. If it doesn't have that, then it's either useless or a complete fraud. In your case, there is a detailed view. Thie picture below was taken from McAfee Knowledge Center article TS102852. You can find the same article by ...


Only top voted, non community-wiki answers of a minimum length are eligible