On Mon, Sep 22, 2014 at 2:15 PM, Daniel Micay <danielmi...@gmail.com> wrote:
> I think it can be solved by using visibility, along with providing a way > to override the visibility rules and call private functions. That means > replacing the current usage of visibility for memory safety with unsafe > fields though, but I think that's important to make the memory safety > boundary work properly anyway. > Just to clarify what I see going on here and how other (type) systems have solved this: For things like XSS and SQLi, the problem is untrusted off-the-wire data being used in what is more or less a "secure" context. Some might refer to this sort of untrusted off-the-wire data as "tainted" and try to use some sort of taint analysis to solve the problem. The TS* dependent type system refers to it as "Un" (i.e. untrusted) and relies on its dependent type system to prove Un data isn't used in a secure context. Very fancy and possibly overkill, but that said, a pretty awesome solution to the problem. There is a *generic* problem here of using such untrusted data in any sort of templating or metalinguistic context. The general problem is OWASP #1: failure to sanitize input, affecting vulnerabilities like XSS, SQLi, and LDAP injection. I am absolutely certain this affects systems like Servo as well ;) Preventing untrusted data from penetrating the secure contexts of the program using the type system has the potential to mitigate the most common security vulnerabilities if done correctly. -- Tony Arcieri
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
