New answers tagged

0

You're code looks right, but it's possible that the cookies you're trying to access are HttpOnly which would not let you access them via javascript. Confirm in Console document.cookie should return "" document.cookie = "username=John Doe"; to set a random cookie value. document.cookie should return "username=John Doe" Try your ...


6

Only the person behind the rejection could answer definitely why they consider it a security issue. I've found the following questions helpful for such a discussion (not necessarily all of them, since it's likely several of them would be answered by a single question): Which type of security issue is this? “XSS” is not enough of an answer, since it's not ...


2

You could have issues if, for example, the API and SPA rely on the same cookie credentials and you don't fully control the closest common higher-level domain. You would have to set cookies on that higher-level domain, which could let attackers steal them if they gain access to a different sub-domain. Not a great situation in the first place, but one that ...


27

It would be more accurate to say that "using two servers e.g. api.myservice.org and www.myservice.org has security implications " --in other words, would normally be blocked by default server CORS config. But there are safe and secure methods to allow this by adjusting those settings. The alternative of configuring URL paths to point to different ...


20

From the information provided, it is definitely not a security risk. As long as proper controls are set on the API endpoint (HTTPS, HSTS, etc.), you should be good to go. One thing to note here is that the myservice.org may be running on a hardened system and with additional protections (such as a WAF). In that case, those controls will have to be applied to ...


0

I think you should assume that every variable that you create, every code on the client side can be modified or read by the attacker in case of an XSS attack. For example, if the attacker is looking for a token that is sent in an API call, he can simply hook/rewrite the function that is used for making the API call at runtime and extract the token before it ...


0

As @zyk's answer states, the & separates URL parameters. The URL parameters get reflected in an <a> tag at the bottom of the source view-source:https://your-lab-id.web-security-academy.net/post?postId=1&payload: <a href="javascript:fetch('/analytics', {method:'post',body:'/post%3fpostId%3d1%26payload'}).finally(_ => window.location = ...


0

Many of the answers now refer to unmaintained packages. Caja seems to be semi-abandoned is browser side and its node port (node-google-caja) is formally unmaintained. express-validator is fine but there's a fair amount of heavy lifting you have to do (i.e. figure out which types of sanitisation you want to carry out which will require security research). The ...


0

In both cases, some malicious script is injected in request data and is reflected back to the client's browser. For Reflected XSS, successful exploitation depends on a single HTTP request (GET or POST) which when replayed from the victim's browser (with help of some social engineering), results in script injection. In some cases this may not be possible. ...


Top 50 recent answers are included