41–50 of 107 posts
Earlier quoted context omitted.
I guess you mean hard realtime. What usually on the web is called realtime is soft realtime IMHO.
Sure I get, but I think it just dilutes the meaning of the term "real-time" to use it in a soft context.
Earlier quoted context omitted.
Avoiding GET requests is not a fool proof way to mitigate CSRF. If your website has just one XSS vulnerability an attacker can send POST requests. It's much better to use some kind of token that is always sent with your forms.
There's nothing stopping anyone from sending POST requests to wherever he wants, even without an XSS. the same-domain origin policy only forbids you from reading the response, not from sending the request. CSRF-wise, POST requests are just as vulnerable as GET requests. Also, if someone does manage to find an XSS vulnerability, using a CSRF token won't be any good - the attacker can simply read the token from your we…
Then if your authentication is cookie based and you allow to delete resource via GET then all the attacker have to do is to insert or tag on any other domain with the proper src attribute to delete your content silently.
These endpoints are a VERY bad idea and are absolutly not REST. RESTful do not mean CRUD.
Earlier quoted context omitted.
I don't think that solves the underlying problem of side effect-ful/dangerous GET requests that may be easily exploited via CSRF attacks. You really don't want to expose POST/PUT/DELETE actions via GET.
Avoiding GET requests is not a fool proof way to mitigate CSRF. If your website has just one XSS vulnerability an attacker can send POST requests. It's much better to use some kind of token that is always sent with your forms.
Reference: https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Re...
Earlier quoted context omitted.
There's nothing stopping anyone from sending POST requests to wherever he wants, even without an XSS. the same-domain origin policy only forbids you from reading the response, not from sending the request. CSRF-wise, POST requests are just as vulnerable as GET requests. Also, if someone does manage to find an XSS vulnerability, using a CSRF token won't be any good - the attacker can simply read the token from your we…
No. Before performing a POST/PUT/DELETE or any other method with side effect to another domain your brother will issue an OPTIONS to get authorization first and will never perform the request if the server do not authorize it. Then if your authentication is cookie based and you allow to delete resource via GET then all the attacker have to do is to insert or tag on any other domain with the proper src attribute to de…
POST requests can be easily sent cross-domain. NO ONE SHOULD EVER think that just because he's not using GET requests he's safe from CSRF attacks.
[1] See http://jsfiddle.net/8xnB3/5/ for example (which sent this comment).
EDIT: Just to clarify - I'm not saying that exposing those endspoints via GET is a good idea, I think its horrible. But people should be aware that avoiding GET does not protect against CSRF, and you still have to use CSRF tokens.
Earlier quoted context omitted.
Oh really? As a non-Node.js guy, I would love to see some others. Can you show me some examples please? Thanks!
Node.js packages are usually small and self-contained. Without typing/APIs Node relies heavily on documentation, so packages which are not well-documented will fall into oblivion quickly. Who'd write a OSS library which nobody can use? My personal favorite, interactive docs! http://coffeescript.org/ I like these ones because of the straightforwardness: http://socket.io/ http://jade-lang.com/ http://mongoosejs.com/ An…
Judging from the description it does what the other 1000+ Node MVC frameworks do. What's the advantage of Sails over them? CRUD scaffolding is nothing new in Node's ecosystem. Apparently their edge is that users can manipulate the database on their own in the default scaffold? EDIT: Downvote without a comment is not constructive. This is a legitimate question. Care to explain?
Sorry to say but such frameworks and ideas are from the last decade (Rails was the main reason why I switched to Node).
Node is excellent from an architectural point of view, but I can't get over JavaScript. I really think web developers have Stockholm syndrome with this language.