3
Security is multi-dimensional. Delivering software as a web application has benefits and drawbacks.
Using software deployed as a web application requires total trust in the server, since the server can replace the code at any time. While browsers have some means to ensure the integrity of a webapp, these cannot protect against changes on the server itself. ...
2
Kerckhoffs's principle states: A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.
So, theoretically, there is no such thing as "too much" released information, and whatever you decide to present to your users, other than the actual passwords, should be safe. Relying on keeping this information ...
2
"big institutions" have very strict policy, multiple stage development chain, dedicated quality team and canary testing implemented. It's not that easy task for single rogue developer to insert anything nasty. Theoretically possible, but not probable.
Moreover, if the attacker is able to insert a DDOS payload, how about some spyware, backdoor, ...
2
Express express.json() only populates the body as JSON if the Content-Type: application/json is used:
$ curl http://127.0.0.1:4000/item -XPOST -d 'itemName=42' -H"Content-Type: application/x-www-form-urlencoded"
posted item name: undefined
$ curl http://127.0.0.1:4000/item -XPOST -d '{"itemName":42}' -H"Content-Type: application/json&...
2
Browsers only send pre-flights when you make a "non-simple" request. A "simple" request is basically "anything an HTML form could send". Setting a content-type other than what a form can send (such as JSON) will trigger a preflight.
HOWEVER... in many cases, you can send arbitrary content as "text/plain" (which doesn't ...
2
This is an undefined header.
As such, how browsers react to it is browser-dependent. It is possible, but very unlikely, that they will still interpret the header correctly. However, I would not bet on it.
Instead, change the header from Strict-TransportSecurity to Strict-Transport-Security.
2
The current answer shows that we currently should not. But at what point in the future can we start to rely on this?
Comparing the data from caniuse and the MDN support tables. You can observe that there is no browser that exists which supports TLS 1.3 and does not support SameSite cookies.
Browser
SameSite
TLS 1.3
Edge
16
79
Firefox
60
63
Chrome
51
70
...
1
Since that's expecting a url (and not HTML tags), have you tried a javascript url?
javascript:alert(1)
Also, are you only testing for XSS, or would you also be interested in open redirect issues?
Legitimate sites that a user trusts with arbitrary redirects like that are great for phishing attacks!
Consider that I get an email with a link:
https://yoursite....
1
Yes it is possible.
In fact that is exactly what was done in the DDoS against GitHub in 2015. The javascript files served by Chinese search engine Baidu were hijacked by China's Great Firewall to include malicious code to DDoS GitHub. The browsers of all users that visiting Baidu (or any website that used Baidu's analytics) would send HTTP requests to GitHub,...
1
I've also faced this kind of situation. The developers has sanitized " to prevent XSS vulnerability. You cannot get rid of ".
And inside the double quote is a single string while the attribute is value. So, you cannot exploit it. Because to exploit you have to bring input out of the double quote anyway.
1
No, if you can't enter double quotes you cannot escape from the attribute value. See the WHATWG spec for details on how browsers parse attribute values. The possible parser state transitions in that state are:
character
effect
" double quote
end attribute value
& ampersand
parse a character reference
NULL
error, but will continue parse
EOF
...
1
I'm not sure I follow, but in any case, you need someway to authenticate they webapps. The web app that is for "test" should never be able to send a code that it is asking for the "prod" data.
A safer way of doing this is to handle that mapping in the backend. The webapps are registered with the backend and the backend knows where to ...
1
You can hide a PHAR inside an image (PNG, JPEG)
You can hide a PHAR file within a PNG image (or a JPEG image) by using a custom data block. You could even declare you own chunk called "phAR" or "phAr", and put a PHAR file into it. I believe this can be readily done with ExifTool. You now have a valid PNG, which actually is a valid PHAR in ...
1
The first answer by Schwern makes the argument that .ENV variables are fine and
".ENV is a convenience and, ideally, is not used in production"
Before that line, you skipped this line:
To clarify, the security and flexibility are gained by putting secrets into environment variables.
If you're not comfortable using .ENV, then just pass the ...
Only top voted, non community-wiki answers of a minimum length are eligible
