I'm not sure I can help you, but this might : https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach tldr (bridge mode): to get the ip of the container (in container CLI) : ip addr show eth0 to get the ip of the host's docker interface (host CLI) : sudo ip addr show docker0

Based on a tip from the https://www.reddit.com/r/ipfs/comments/rfe48b/comment/hoheoko/?utm_source=share&utm_medium=web2x&context=3 who says Hi, you have to edit ipfs config file you need to change the Address field to "/ip4/0.0.0.0/tcp/5001" I was able to solve the issue. To do so, I ran ipfs config Addresses.API /ip4/0.0.0.0/tcp/5001 and then systemctl restart ipfs Now I get the expected result

The parameter should come at the end of the URL: Invoke-RestMethod -Uri https://gitlab.com/api/v4/projects/1234567?private_token=$my_private_token I prefer to pass the token in the header: Invoke-RestMethod -Headers @{ 'PRIVATE-TOKEN'=$_my_private_token } -Uri http://gitlab.com/api/v4/projects/1234567 https://docs.gitlab.com/ee/api/#personalproject-access-tokens

TL,DR: It's impossible to do so client side. Client side validation is just a client convenience, not useful to really validate anything. You don't want the client to mistype his email, putting an invalid char somewhere, and have to wait the form being submitted, the server parsing it, and sending back an error 5 seconds later, you want the error to show instantly. You validate on the client, but you ignore the client validation entirely and validate again on the server. If the validation is made client-side, the client may submit the request by hand, bypassing all validation. Even if you use hashing, signing, obfuscating or anything else, the result is an HTTP request and the client can intercept it and tamper it. If your use case is what you asked, server validation it's not difficult at all. Have a table with all questions and all valid answers, and check every client answer with the table. On the first invalid answer you stop the processing and send back an empty page. the number of possible permutations could make validation very difficult. You have to choose between server-side (from trivial to very difficult) and client side (not possible at all). I believe the choice is easy.

It sounds like you are the data controller for user submitted data, i.e you are allowing users to access a system, input data then fetch that later. You do not describe the type of data you are storing. If I assume this is dynamic user input to your host system, then you are now relying on users not putting any PII there. If they do you will then be in a problematic situation as anyone else can now access this PII publicly. Even if the above assumptions are incorrect, you might consider first thinking about the data implications. As a data controller/processor you will have legal and regulatory commitments (GDPR for example). If you can be 100% sure the data will always be public and contain no information that could land you or your users in trouble then public consumption of the data might be ok. Note I say consumption as public access may still be a problem. Access to your system will consume resources. Without any form of authentication you will have to reply on request meta data (IP address etc). This might be enough to let you build appropriate throttling and blocking controls, but only you will know that. I have no idea of the context of your system, but you may also consider the long term impact of sharing 1 users data with many. Lets imagine for a second this is some form of blog content the user is submitting/retrieving, that content gets a lot of traction, your user loves you and your platform, however unknown to you and your user is someone else is also consuming the same content and hosting it elsewhere, making a profit from someone else’s data.

Our application is a pure backend server. Serving JSON APIs to the users. Users will be calling these APIs from their backend in 99.99% of the cases. ... It does not matter what the API is serving or how the user is supposed to call the API. Attackers don't care about how something is supposed to be used but typically rely on not intended functionality. If authentication credentials are automatically sent and no cross-origin detection or protection is done, then an authenticated client can be tricked into making in authenticated requests controlled by the attacker. Authentication credentials are automatically sent with cross-origin requests when basic authentication is used or cookies - although many modern browsers nowadays limit the problem by making cookies same-site by default. Other automatically sent authentication methods are client certificates or Kerberos resp. NTLM tickets. If the attacker can induce the client to make such a request then the attacker does not need to actually know the authentication information - the client will add these by its own to the request. Sometimes "authentication" does not rely on specific credentials but simply allows anything which comes from specific IP addresses or network. While a cross-origin request is triggered from "outside" it is using the clients browser to actually do the requests which thus comes from "inside" and is treated as authenticated. If the API instead relies on something like an authentication token which explicitly needs to be added to each request, then the attacker would need to know the authentication credentials and cannot blindly trigger an authenticated request. In this case CSRF would not be doable. Similar if the API requires requests which are not https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests for example by requiring special HTTP headers, then CSRF can not be done unless the site employs a weak (non-default) CORS setup. can we go ahead and mark this flaw as false positive? Too few is known about your actual API to decide on this.

Half-serious response: throw the whole thing away, WAFs are somewhere between "more trouble than they're worth" and "worse than useless". They're like antivirus except their detection (both sensitivity and accuracy) is somehow even worse, they break your site when they misbehave, and there's no way for a legit user to bypass them. The protection they provide is marginal; a competent attacker or even well-written script can almost always bypass them. (Reasons this is only half-serious: there are a few things that a WAF can meaningfully detect with confidence, the alerting can be useful even if the blocking is overzealous, and WAFs provide a central management point for other useful traits like blocking suspicious source IPs or 0-day known exploits... though how well they do at that is highly variable. There is perhaps no single thing that a WAF is the best answer for, but they are a convenient place to put a lot of occasionally-valuable checks.) Fully-serious response: you should be able to disable that rule or at least downgrade it to "notify" from "block" (possibly even only for that endpoint) and there's no good reason not to. Preventing SQL injection is a solved problem - just use parameterized queries and avoid any form of string concatenation in SQL - and it's impossible to prevent with a regex anyhow. You could also possibly enable a mode between "notify" and "block" where e.g. allow the first nine flagged requests in a minute are logged but allowed, and the tenth or later one gets blocked... but of course that risks filling up logs with false positives and blocking legit users during high-traffic periods. Base64 encoding is an interesting idea; some (few) WAFs will recognize this and decode it, but most will ignore it. The reason not to do that, though, is less about the WAF and more about the actual security you should have behind it; any time you're adding encoding and decoding to your flow, you risk performing a validation or escaping step (e.g. for XSS) on the encoded data, which of course finds nothing. (It is also true that, assuming the WAF doesn't itself recognize and decode base64, you'll be in effect completely turning off its content rules for that endpoint, even the ones that are theoretically adding value.) You asked why WAFs are so popular then, and it's a fair question. In my experience, the answer is some combo of: Lying vendors promising they can solve all your security problems[*] to ignorant and credulous executives[**] People coming to expect it (encouraged by the same vendors, of course) and thus making it a contractual requirement to have one A "checkbox" approach to security where the question is "do you have XSS protection" and not "has anybody competent ever checked if they can get XSS on your site" Lots of people who can't be bothered to read even the basics of web security and thus deploy sites with gaping holes and, when this bites them, take the least-effort approach to "fixing" the problem The fact that there are in fact a lot of script kiddies out there trying dead-easy-to-block attacks, so a WAF sure looks like it's providing value by blocking them all (and is in fact providing some value, if you're in the group mentioned in the previous point) Actual value even to people who have put in any meaningful security effort, in the form of e.g. malicious IP filtering and similar checks that it's reasonable to delegate to external software. Even though in most cases you could do better with a fine-grained and context-aware filter implemented in your server, it'd just be more effort to create and maintain [*] Usually described as "Prevent the entire OWASP Top 10" or similar. This is neither accurate (there are several items in the current top 10 list that a WAF will never be able to handle even in theory), nor sufficient (lots of critical security vulnerabilities are not in the current top 10, though some have been in the past). [**] As far as I can tell, there is simply no accountability in this field, and the vendors know this so they just don't care. My employer recently was faced with the requirement to procure a WAF in order to close a big contract. Every vendor promised us a miracle solution. Every time, I was able to find multiple pages of bypasses in under a day's work. They never cared. We eventually picked one - a really big, well-trusted company's product, you've heard of them - largely on the basis of "easy to deploy, it'll stay out of our way, and doesn't cost too much". Our bug bounty testers didn't even break their stride, using bypasses I hadn't even noticed in those quick tests.

Is there any advantage in using HTTP with an encrypted message instead of HTTPS? No, and I can list a handful of disadvantages: It's not properly tested and vetted Homegrown code usually lacks quality It creates a huge point of failure because the developer is not a cryptographer It's not easily updated with better algorithms It's not secure It performs badly It complicates the code without adding any benefits Is it common to do this? Unfortunately yes, it's common. It's " https://www.schneier.com/blog/archives/2011/04/schneiers_law.html " working: Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break. Developers aren't cryptographers, so they devise ways to encrypt data that do not work well, and it's way worse than anything already done. They do this because they don't know enough of crypto to know their code isn't secure at all, and because they don't know enough of crypto to know the alternatives. Throwing XOR and MD5 and DES on the blender can return opaque looking strings, but returning opaque AND secure strings is a very different thing. Should it be done like this? Absolutely not. If the backend for some strange, bizarre reason cannot use HTTPS, at least use proper encryption. There are good libraries out there that can properly handle encryption ( https://nacl.cr.yp.to/ for example), so use one of them. And if you can, bully the dev on the other side to employ good crypto. If you cannot bully him, find someone that can.

Looking at your example requests, it looks like the application escapes ', but fails to escape \. This means that you can inject a ' to break out of the string context (via \'), but you can't use a ' in the rest of your injection (even if escaping via \'; which is giving sqlmap problems, so I'd suggest manual exploitation). You have this: ' -> \' \\' \\\' What I would do first now is repair the query. Something like Landing\'))--x- (you may need to adjust the closing bracket count, I'm going of the error message). This should again give you a 200 and some results. Once the query is fixed again, you can now inject your desired query. Landing\')) union select 1 --x- might work (an alternative would be blind injection, eg Landing\')) and substring(version(),1,1)=5--x- (or the mssql equivalent)). My guess is that sqlmap is running into problems because you can't use ' in your injection (except for the initial \' to escape the existing string context). Imagine eg an injection into SELECT 1 FROM table WHERE id LIKE '%[userinput]%'. Injecting \'--x- works, as it gives SELECT 1 FROM table WHERE id LIKE '%\\'--x-%' (which then runs SELECT 1 FROM table WHERE id LIKE '%\' on the db). But injecting \' and x = \'test wouldn't work, as it results in SELECT 1 FROM table WHERE id LIKE '\\' and x = \\'test' (which runs as SELECT 1 FROM table WHERE id LIKE '\' and x = \'test' on the db, which is invalid because of the extra \ in front of 'test').

Yes, that is a valid concern. As for how to mitigate it, you have several (not mutually exclusive) options: One thing that you've already implemented is not doing slow key derivation on every request, but rather having an authentication endpoint that takes a passphrase (or equivalent), applies a slow key-stretching KDF, verifies the correctness of the result and returns a (typically time-limited) token that can be used for fast authentication of subsequent requests. What such a token should contain depends on your backend implementation. If you can easily and securely store session data on the backend, probably the easiest solution is to simply generate a (cryptographically) random token of, say, 128 or 256 bits and return it to the client. You can then store any sensitive information needed for backend processing — possibly including the master pseudorandom key output by the KDF, or one or more subkeys derived from it — in the backend session storage keyed by the random token. If you want your backend to be stateless, things get more complicated. One option, if you can arrange your backend to have access to a secret encryption key, is to use something like a JWE token https://datatracker.ietf.org/doc/html/rfc7518#section-4.5 with the secret key (using an authenticated encryption algorithm — but fortunately all the https://datatracker.ietf.org/doc/html/rfc7518#section-5.1 supported by JWE are authenticated!) and containing any information the backend needs for fast authentication. Depending on what you're doing in the backend, that might include one or more keys derived from the KDF output, but for applications that don't need to do any per-user encryption or decryption on the server, even just the ID of the authenticated account may be sufficient. Now, obviously, just restricting slow key derivation to a single endpoint won't prevent that endpoint from being DoSed. But it does reduce the server load from key derivation in normal usage, and it also paves the way for further DoS countermeasures, such as: Rate limit your authentication endpoint. With appropriate rate limits in place, a DoS attack on your authentication endpoint should only be able to deny access to that endpoint, but not interfere with clients that have already authenticated. While that's still not ideal, it's a significant improvement, especially if you allow your clients to establish fairly long-lived sessions (say, 1 day). For some simple types of DoS attacks, finer-grained rate limiting based on e.g. source IP address can be even more effective than just a single global rate limit. Yes, distributed attacks e.g. via botnets can circumvent such rate limiting, but the reason why server-side KDFs can be tempting DoS targets in the first place is because they can allow easy DoS without the massive bandwidth of a botnet. If your attacker has a botnet, they probably don't need to target your KDF. If you cannot or don't want to implement explicit rate limiting, a "soft" alternative can be to run your authentication endpoint on a separate server, or at least in a separate resource-limited container. This also prevents a DoS attack on the authentication code from taking down the rest of the service. Of course, for this to work, the authentication server and the rest of the endpoints need to share access to the same session storage, and/or to the same token encryption keys. As noted in https://security.stackexchange.com/a/257285 , you could also require the client to submit a proof of work as part of the authentication request. Essentially, this forces the client to spend as much effort on the request as the server will spend on computing the KDF, or at least some reasonable fraction thereof, thus eliminating or reducing the attacker's leverage. However, I would not actually recommend this approach, since if you can do this, there's an even better alternative: IMO the absolute best way to avoid DoS via slow KDFs is to offload the slow key derivation to the client. Basically, instead of having the client send a passphrase to the server, which then uses a slow KDF (such as PBKDF2 or Argon2, etc.) to derive a pseudorandom master key from it, just have the client run the slow KDF and send its output as part of the request. This does require somehow ensuring that the client knows which salt, iteration count and other KDF parameters it needs to use. Probably the easiest way to handle this is simply to have the client request these parameters from the server in a separate request. For most parameters this is no problem (although the client should definitely at least enforce a minimum iteration count!), but the salt does require some extra consideration: If you don't want your pre-authentication endpoint to disclose which user IDs exist on your system, you'll have to generate fake salts for nonexistent usernames, e.g. by hashing the username together with a server-side secret. (Of course, preventing the leakage of user IDs is not always either desirable or practical anyway.) In any case, you'll leak the user's salt, which means that an attacker may observer any changes to it. If you follow the standard procedure of changing the salt whenever the user changes their passphrase, this can allow an attacker to both confirm that a user ID exists (assuming your fake salts don't change) and that the user has (or has not) changed their passphrase since the attacker's last query. In general, this leak seems more or less unavoidable, except by using a fixed salt for each user (which has its own issues). You may also want to have the client augment the salt sent by the server e.g. by appending the user ID and possibly some server- or application-specific string to it. This is to prevent a MiTM attacker from tricking the client into using a salt and KDF parameters belonging to the same user on another service, which could be an issue if the user used the same passphrase for both services. Also, you'll probably still want to run the KDF output sent by the client through a second KDF on the server — but this second KDF can be a fast KBKDF such as https://en.wikipedia.org/wiki/HKDF ( https://datatracker.ietf.org/doc/html/rfc5869 ). Depending on your application, this may not be strictly required, but it doesn't hurt and can have various advantages. In particular: it allows you to derive multiple subkeys and/or check values of any desired length from the KDF output, without the client needing to be aware of this; if you're using (part of) the KDF output for user authentication, by comparing it with a "password hash" string stored in your user database, having a server-side KDF step prevents an attacker who compromises your database from using the stored hash directly to authenticate; it protects you against potential attacks using malformed input by ensuring that, whatever the client sends you, it goes through HKDF before it touches any other cryptographic code on your server.

Things didn't changed much since them. Servers would render the entire page on their side and send it to the client, and bad designed authentication would mean someone accessing things not intended to. Today it's basically the same, but instead of sending the entire page, the server sends only the information needed for the client to render the page. CORS does not protect anything on the server: it's intended to protect the client, not the server. It prevents a malicious actor from loading foreign resources in the context of a site and stealing information. Impersonating the client: this is not possible if you have authentication in place. You should have an endpoint on the API side that receives a login and password, and return a token. The client them sends this token on every other request. Should we back to the good old days when dealing with sensitive data? You don't need to. Have a proper authentication endpoint handling authentication tokens, send the token on every sensitive request, and you are done. Having the server send a sensitive json, HTML, pdf or mp4 file does not make any difference at all.

the backend API server was reflecting the Origin header from a credentialed request in the Access-Control-Allow-Origin header I assume by this you meant that it's reflecting arbitrary Origins, not just trusted ones? Assuming that the API uses cookies (or HTTP basic/digest auth, which is rare), then this is absolutely a problem. I don't believe there is a CORS issue here as for most of the endpoints there were preflight requests performed Do those preflights actually block the request if it comes from an untrusted origin? Usually if a server is reflecting arbitrary origins in ACAO, it does that for both preflight and non-preflight requests, and usually if it supports preflights at all, it always returns the same set of CORS permissions (aside from ACAO) in all preflight responses (or at least all that have allowed origins). Preflights by themselves don't inherently prevent CORS issues. They're a "checkpoint" of a sort - a place where security controls can be enforced - but that depends on them being configured correctly, and "reflect the origin in ACAO, plus ACAC: true" is definitely not configured correctly. Does this mean that an attacker could cause a victim to login to this site by issuing an authentication request from their own attacking server Sounds like you're describing "login CSRF", which most sites are vulnerable to (it's possible to put at least some protections in place against it, but almost nobody does). How big of a deal it is depends on things like how likely the user is to notice being signed into the wrong account, and how big the risk of the user sending sensitive data to the wrong account would be, and so on. Of course, it's also possible it won't even work, because... ... before receiving an Authorization token If by "Authorization token" you mean "Bearer token", sent in the HTTP request header "Authorization"... then all of this is irrelevant. CORS misconfiguration, like CSRF, is only really a threat when the user is authenticated via something that the browser will send automatically (cookies or HTTP basic/digest auth). Bearer auth tokens are not sent automatically, so for them there is basically no risk of either CSRF (even login CSRF, because the returned token won't be stored in the relevant site) or CORS misconfig (because without knowing the header, it can't be set by the attacker, so the attacker's requests will be unauthenticated, there's no way to steal data from the user's account or take actions on the user's behalf). It's the important details of how your auth works, like whether you use cookies or Bearer tokens, that really matter for questions like this! Is there any difference or security considerations if the ACAO header is reflecting the Origin header for credentialed requests as opposed to having it set to a wildcard (*)? Leaving aside the possibility of Bearer tokens, yes there absolutely is! Combining ACAO: * and ACAC: true is a violation of the spec and the client is required to treat it as though ACAC was false / absent. Obviously that's not the case for ACAO with an actual origin, or else ACAC would never have a meaning at all. Because ACAO: * is always treated as uncredentialed, it it can't be used to steal private information from the server. This doesn't prevent CSRF, of course, but usually you don't need XHR/fetch to do CSRF at all.

When securing a back end, it is useless to do any assumption on the origin of the requests. Said differently, you must be prepared to received forged requests that the frond end could not send. That means that asking the app to stop sending request is definitely not a way to secure the back end. On the other hand, having the app being aware that it is blocked for failed login attempts could be used to display a user message explaining the reason why they cannot use the app, and when they could expect to be able to use it again. So it could certainly provide a better user experience. But it is unrelated to security.

Even though system A doesn't store card data, it very much sounds like it processes and transmits it. So it will most likely be in scope for SAQ-D. This needs to be done before the system starts accepting card details, not "eventually". This could probably be be a separate PCI scope from system B (although if both systems are owned by the same organisation, you're probably just making more work for yourself that way). So while it may not impact on whether or not System B is PCI compliant, it will impact on whether your organisation is PCI compliant - and that's the more important issue. If you get compromised and end up losing card details, saying "one of our systems is PCI compliant" isn't going to fly.

You need to add "cookie": "cookie value" to JSON, which You create while calling to scan/$taskID/start

By default, no. Those are files used to render pages on server side. If you will not modify the configuration of where from static files are hosted or the IIS setup (open directory browser feature) you should be secure.

The definition of malware per Google: software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system. It's really an argument of semantics, but "malware" is not really a threat to APIs, as in what is typically considered malware isn't really applicable to APIs, but malware can definitely be planted via vulnerable APIs. For example, achieving RCE via insecure deserialization could allow attackers to drop malware on the underlying host, but the malware has no natural or inherent relationship to the APIs. Would there be any justifiable benefit of malware scanning such connections? This is usually done, but worded in a different way. IPS (Intrusion Prevention) and IDS (Intrusion Detection) solutions, such as WAFs (Web Application Firewalls) perform similar behaviors. However, they aren't scanning for "malware" in the essence of "software", they're scanning for malicious HTTP requests. That being said, AVs and EDRs would still be beneficial in the case that malware is planted by way of an API vulnerability.

There are different HTTP methods that can be used to preform those operations such as DELETE, PUT, GET and POST. Because of the way certain backend frameworks work, having different methods is a huge advantage as you can limit functionality according to the method being used. What you have implemented is (I assume) using the POST method with an indicator of what operation to preform. From a security point of view, the design of this doesn't matter (unless exposing a security issue). What does matter is how you limit functionality and verify permissions. As long as that functionality is implemented properly, it is theoretically okay. To answer your questions: I would not consider what you have described a security issue, just bad design. As I stated in 1, I would see this as bad design as it opens a lot of development issues. I would recommend viewing the https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html

I had the exact same problem and it turned out there were three things going wrong: The JS code doing the request using Axios, an HTTP library which has a bug around cookie handling: https://github.com/axios/axios/issues/2149 . The fix was to use plain fetch and specify credentials: "include" in the options. Without this option, cookies are not included in cross-domain requests. The server was not including the Access-Control-Allow-Credentials header in the response, which has to be set to true on both the login endpoint (for the Set-Cookie to be accepted and stored by the browser) and the refresh-session endpoint (for the cookie to be sent back, here the OPTIONS response is the relevant piece). I set Same-Site: Strict in the cookie attributes (and prefixed the Cookie name with __Host-) assuming this would allow the cookie to only be sent back to the same domain but it resulted in the cookie not being stored at all. Same-Site has to be None for the cookie to work in cross-origin requests at all and the __Host- thing also seems to block the cookie from being stored when it comes from a different host. Omitting the Domain cookie attribute should be enough to stop the cookie from being sent to other domains.

Like @user said in the comments, Hydra does this pre request to get the inital cookies of the webpage. You can set another webpage for the pre-request with c= as optional parameter after the check condition like so: hydra -l user -p pass 127.0.0.1 http-get-form "/api/route/:password=^PASS^:false:c=" This way hydra does not use the actual route to fetch the cookies and my problem is solved.