As Chris mentioned, it's not about using the type system to create safety. We're assuming that exists, the idea is to gate unchecked access to the data (which *is* required for libraries created for generic use) with the `unsafe` keyword. However, many seem to be of the opinion that `unsafe` is just for memory safety, in which case it would be nice to have a wider range of `unsafe` attributes (or something) which allow us to gate methods that are prone to SQL injection (etc etc).
-Manish Goregaokar On Tue, Sep 23, 2014 at 3:01 AM, Tony Arcieri <basc...@gmail.com> wrote: > 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 > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
