97

I think you are very confused about what both CORS and SOP do... neither is relevant to these attacks at all. There are lots of ways to bypass client-side validation. HTTP is just a stream of bytes, and in HTTP 1.x they're even human-readable text (at least for the headers). This makes it trivial to forge or manipulate requests. Here's a subset of ways to do ...


73

Not really. I'd say it depends on your threat model. There might be other threats that don't need to use those ports in order to compromise your server. The first example that I can think of right now is a supply-chain attack. When you update any software on your server, if the updated software has been compromised by a supply-chain attack, your server will ...


69

This particular vulnerability indeed has a name. It is called Server-Side Request Forgery (SSRF). SSRF is when a user can make a server-side application retrieve resources that were unintended by the application developer, such as other webpages on an internal network, other services that are only available when accessed from loopback (other web services and ...


57

PBKDF2 and other key stretching algorithms are meant to be slow and take the same amount of time whether the input password is correct or incorrect. To reduce computational load and latency for your user, the API should authenticate once via login credentials and issue a revokable or time-limited session token that is verified by a simple lookup.


52

This is what I usually do: The user asks for a password reset. The system asks for the registered email. The user enters email, and no matter if email exists or not, you say that you sent a reset link. The server stores email, expiration and reset token on a reset_password table When the link is accessed, expiration is checked and a form to reset the ...


49

... SRC=my.server.public.ip DST=109.89.132.126 ... ... PROTO=TCP SPT=81 DPT=587 ... RST ... This is a RST. It will be generated by your server if a remote system (in this case 109.89.132.126) tries to connect to a port on your system where no one is listening. Given that no one is listening on port 81 on your system it is sufficient that 109.89.132.126 has ...


35

No. There are multiple things which can be attacked on a target computer, and a serving application (httpd or sshd for example) is just one of those things. Remember, there is an entire network stack between the physical network port on the network card and the application handling the actual traffic (ie sshd) - in this stack there includes things like ...


35

Reverting the changes every 30 minutes is not a solution. You absolutely need to find out the root cause and stop this from happening by removing the vulnerability or the persistence. This may include monitoring the logs and other forensics, but also a fresh installation of WordPress (or in worst case the entire server) might be required.


31

We store the URL instead of the image. In addition, this will add information and privacy risks. Let me show with a visual demo. If you try to upload any image to StackExchange, you will notice that the image gets hosted by imgur.com. The SE server fetches the images and uploads a copy of it to its private server. I will use a popular and innocent meme ...


28

Instead of uploading an image, the user can provide the (self-hosted) URL of an image. We store the URL instead of the image. You mean these kind of JPEGs? It is a bad idea. First of all, you will have to check the validity of the image every time you use it. That takes time. I assume that the database is used by other users, and you will have no control ...


23

Maybe a very short answer will help as well. I never thought about it much, I just thought this meant someone could bypass the validations by making a request on something like Postman. But then I learned that with a same origin policy that's not possible. The same-origin policy is something that browsers voluntarily implement to protect their users. It ...


18

A few possible explanations: CSP: Check headers and meta tags. I agree that the onerror executing makes it unlikely, but I am not sure it would be impossible. Browser XSS filter: Only an issue if you are doing reflected XSS. Turn them off, or use a browser without an XSS filter. Malformed HTML: Are you sure the script tag is actually being interpreted as ...


16

You should not trust the client. So if the client is able to send their username during the stage where the new password is entered, what happens if they change the username to someone else's? They will be able to reset the account of another user and take over the account. @ThoriumBR's answer is of course correct. Another option is to store no state on the ...


14

... wanted it to be secure from attacks from the application layer. ... website is allowing introspection from Burpsuite ... detect an insecure SSL certificate from the frontend using JS? Based on your previous question you want to protect your application against reverse engineering and manipulation by the end user itself, i.e. the user controlling the ...


13

An attempt to list some ways to hack into a server without using http or ssh: Using a vulnerability in Management Engine Using a bug in a network board firmware or driver Using something not very secure in the virtualization platform, having a legitimate access to (or hacking into) a neighbouring virtual machine Exploiting some bug in the IP or TCP driver ...


11

It's most likely fine. There are a few situations in which you want to communicate with localhost using HTTPS - such as running a local webserver for web development purposes or some other service that offers a web interface. The way to do it "properly" is to generate a self-signed certificate, set up your web server to use that certificate, and ...


10

The main reason might be neither, but the ability for conditional authentication steps. Some services e.g. support multiple single-sign on (SSO) providers, and the username is required to pick the correct SSO to forward the user to. Some may even have different authentication methods altogether. From security and privacy perspective this is also a bit ...


10

Postman and same origin policy aren't obstacles. To understand this, I need to explain why, as a developer, you virtually never trust the client/front end. Front and back end trust If someone controls a computer, they control what it sends the server. That's literal: every last byte of it, every last header or request, every last POST field in a form or GET ...


10

PBKDF2, or for that matter, any password hashing algorithm, is designed to be tunable so it can take a variable amount of time, depending on the security level to be desired. The amount of time it takes will be constant assuming the same parameters are taken, whether the password is correct or incorrect, since it's impossible to determine whether it's ...


9

Your backend is accessible via the network. That means I don't need to use your frontend. I can find out what endpoints it uses, and and what format the request looks like, and use my own tools to send requests that your frontend would never allow. You must never assume that a request hitting your backend actually originated from your own application. It ...


8

You still need "traditional" CSRF-protection. Maybe this will change in the years to come, but as of writing the SameSite attribute should be viewed more as defense in depth than your one and only line of defence. This is for a few reasons: According to caniuse.com, there is currently only browser support for 85% or 92% (if you count partial ...


8

First of all, as I mentioned in a comment under the question, this method will not work if the user has any browser extension running that modifies the page source since the signature would no longer remain valid. This also applies to antiviruses that intercept and inject scripts into web pages. Browser extensions can easily be disabled but disabling the ...


7

HTTP Strict Transport Security (HSTS) RFC 6797: 8.4. Errors in Secure Transport Establishment When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ("User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying ...


6

Installing a desktop application implies 100% trust in the service provider. It is the hypothetical security equivalent of them gaining privileged remote code execution on your web browser--a vanishingly rare security event. Proof of security concept: the provider can do significantly more to your device with the desktop app. Trust has many facets; Discord ...


6

$pattern1 = '/[^[:print:]]+/'; // remove non-printable characters $pattern2 = '/[ \t]+$/'; // remove whitespace at end of string $pattern3 = '/^[ \t]+/'; // remove whitespace at beginning of string $pattern4 = '/^[\\\\|\/]+/'; // remove leading slash if one exists $pattern5 = '/^[\.\.\/|\.\.\\\\]+/'; // remove all ../ and all ..\ if any exist echo "...


6

How do hackers trick frontend validation? They don't. They simply don't do it. The question is based on a simple flaw of thought. For attackers there is no frontend validation as they simply do not use the frontend your normal users use (unless they want to for some reason). One core idea of backend and frontend is to separate both. In most scenarios that ...


6

PHP offers great opportunities to mix configuration data, business layer code, HTML and javascript in the same script. Yet IMHO it is not a good practice, because it tends to make writing and executing tests harder. Here the list of allowed IP addresses is a configuration data. Having to search such data through the code if you later install the application ...


6

when we say that PBKDF2 is slow does it mean that it's going to take a lot of time to hash the password and validate it, therefore the service not being responsive enough for the end user? It won't add any meaningful latency to your REST API. A computation that takes 100ms once will not be noticeable to your clients, but will be prohibitively slow for ...


5

Closing ports is one very early line of defence. When a port is open, there will be some piece of software running which handled the data entering on that port. That software can have bugs that allow an attack to succeed. If you open 100 ports, there are 100 pieces of software that are potentially insecure. With two open ports only, there are only two ...


5

The automated scan result is showing a potentially exploitable issue. Like every other automated scan result, you would have to perform a false positive analysis. The easiest way to analyze this would be to perform a code review to see how the affected parameter is handled server side. If this is a blackbox/ graybox security test and looking at the code is ...


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