• StarLite (unregistered) in reply to cm5400
    cm5400:
    Anonymous:
    Jeff S:

    Sean Connery:
    I don't think this is that bad. Its possible they used a specific user to do the query.

    SQL server and I'm sure other database servers allow you to restrict what users can do.

    But I doubt it.

    I think you better stick to acting ....



    How do you think ad-hoc query interfaces work? I've written one. I suggest you stick to /.

    To query a database passing the TSQL in a URL is not bad, just the user that it connects as must only have read access.  But when you pass TSQL through a URL to CRUD a database, that is bad.


    Then you'd make a query that takes 10 minutes to run and clog up the whole site/system/database...
  • (cs)

    This reminds me of a web page I saw recently.  I just followed a deep link from one site to another.

    It was an ASPX page, and the page crashed immediately upon viewing (apparently, someone had deleted the line in the C# code where the SqlCommand object is declared.).  But the important points were:

       1) A externally viewable page on a live commercial website crashed repeatably (and unavoidably).

       2) A external users could see the error message and the ENTIRE source code to the page.

       3) A quick glance at the source shows that a SQL injection attack would be trivial.

    I email the site explaining the above (If you customers are explaining SQL injection to you, you need to have a talk with you development staff).  The page doesn't crash anymore -- I haven't tried to see if the injection vulnerability is still there...

     

  • Sean Connery (unregistered) in reply to Ytram
    Ytram:
    Anonymous:
    DelawareBoy:

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.



    The assumption is that sql query strings cannot be made safe. I contest this by saying that if you use appropriate database security, you can use query strings in a subset of applications.

    But that subset is probably limited to querying applications.


    There's a couple of problems with your stance:
    1.  If you're building SQL strings at the presentation layer, you're doing something wrong.
    2.  Exposing a SQL string to the user via an encoded URL is just plain a bad idea.  You do not want users to know what table and column names you have.


    1. Other representations of the SQL are open to the same arguments
    2. Unless you do - This is why it probably only applies for a subset of applications

    In my case, they wanted to be able to drill down to the table level, but only allow certain fields/tables. And it had to be exposed as a web service (for external reporting). Its all coming back to me now.

    But to clarify things, I didn't use SQL strings, I just think there are cases in which you can allow free text queries if you have locked down your database appropriately.
  • Anonymous (unregistered) in reply to Sean Connery
    Anonymous:
    Ytram:
    Anonymous:
    DelawareBoy:

    I tend to agree here. When should someone put security matters in the backseat to something else? I'd really like to hear it. If Microsoft is any example, I understand they require a security plan, threat modeling, etc., prior to even starting to plan the project.



    The assumption is that sql query strings cannot be made safe. I contest this by saying that if you use appropriate database security, you can use query strings in a subset of applications.

    But that subset is probably limited to querying applications.


    There's a couple of problems with your stance:
    1.  If you're building SQL strings at the presentation layer, you're doing something wrong.
    2.  Exposing a SQL string to the user via an encoded URL is just plain a bad idea.  You do not want users to know what table and column names you have.


    1. Other representations of the SQL are open to the same arguments
    2. Unless you do - This is why it probably only applies for a subset of applications

    In my case, they wanted to be able to drill down to the table level, but only allow certain fields/tables. And it had to be exposed as a web service (for external reporting). Its all coming back to me now.

    But to clarify things, I didn't use SQL strings, I just think there are cases in which you can allow free text queries if you have locked down your database appropriately.

     

    I have a hard time bashing this guy TOO much.  He is the reason several of us have jobs after all (cleaning up his shitty code)!

  • (cs) in reply to WTFer

    WTFer:

    I think is similar to what happens with Windows security vs Unix security. It's better to close everything and start opening things little by little, instead of giving everyone administrator priviledges. The same applies for SQL is better to create your own secure interface than living sql open and then trying to close it down.

    Not sure what you mean here.  I'm going to assume that you're trying to suggest Windows has bad security because it allows users full access, then you can limit those users in certain ways.  Whereas with *nix you create a restricted user then grant access in certain places.  There is only one problem with this.  It's completely false.

    (Those of us who have actually set up a Windows box in the last few years can skip this bit while I explain it)

    You see, when you set up a Windows box, you get the option to create a number of users.  The installation sets up an admiistrator account (essentially the same as the root account in Linux), and then you create other users.  These can be of different types, ranging from "guest" (very few rights) through to "administrator".  You can also do this during the installation on XP.

    The WTF I see most often is when people think the latest version of Windows is Win98!

  • Sean Connery (unregistered) in reply to Anonymous
    Anonymous:

    I have a hard time bashing this guy TOO much.  He is the reason several of us have jobs after all (cleaning up his shitty code)!



    Ok smart guy, what would you do?
  • Mira (unregistered) in reply to Sean Connery

    Seen on the website of a famous french insurer, who for sure knows how to manage security risks !

    I was tipped by some text in a familiar language that was stealth appended to my search text. Luckily I was on a slow link so I was able to see the change before the result page loads. So I had a closer look at their function library. The following code is the javascript code triggered upon submitting the search box.

    function declencherLienRecherche(formulaire, application, nomPage, start) {
            cond="";
            if (application==null || application=="") {
                    //cond += " AND ( FIELD DbCategories CONTAINS "+categorieWCM+" O
    R FIELD DbCategories CONTAINS "+categorieFAQ+" OR FIELD DbCategories CONTAINS "+
    categorieLexique+")";
                    cond += " AND ( FIELD DbCategories CONTAINS "+categorieWCM+" OR 
    FIELD DbCategories CONTAINS "+categorieFAQ+" OR FIELD DbCategories CONTAINS "+ca
    tegorieLexique ;
                    for (i = 2; i < nombreBaseWCM+1; i++) {
                            cond += " OR FIELD DbCategories CONTAINS "+ categorieWCM
     + i ;
                    }
                    cond += ")";
            } else if (application == categorieFAQ) {
                    cond += " AND ( FIELD DbCategories CONTAINS "+categorieFAQ+")";
            } else if (application == categorieLexique) {
                    cond += " AND ( FIELD DbCategories CONTAINS "+categorieLexique+"
    )";
            }
            document.forms[formulaire].action = lp[nomPage];
            document.forms[formulaire].queryWCM.value +=cond
            if (start!=null && start!="") {
                    document.forms[formulaire].queryWCM.value += '&start='+start;
            }
            document.forms[formulaire].submit();
    }



    Full plain text source of their javascript for the curious, for educational or satirical purpose only :

    http://guy.perville.free.fr/declencherlien_js.txt

    Mira
  • Mira (unregistered) in reply to Mira

    It seems that half the javascript code just got eaten on submit.
    Even this board software will not manage to hide the WTF above.

    Mira

  • (cs) in reply to El Duderino
    El Duderino:
    Why is it wrong to expose your SQL in the presentation layer?  What "rule of programming" is this breaking?

    Basic separation of concerns is the rule it breaks.  The presentation layer is for presenting things.  The data layer is for data access.  It's so simple.
  • Rodyland (unregistered) in reply to Sean Connery

    Well, for my $0.02, if you want to give your users access to table for, for example, ad-hoc SQL or whatnot, you should create views on your tables and use them.  Much cleaner, much safer, much easier to maintain, all that good stuff, IMHO.

  • (cs) in reply to El Duderino
    El Duderino:

    For the sake of discussion, I'll play the Devil's Advocate.

    Assuming appropriate database security:

    There's a couple of problems with your stance:
    1.  If you're building SQL strings at the presentation layer, you're doing something wrong.
    2.  Exposing a SQL string to the user via an encoded URL is just plain a bad idea.  You do not want users to know what table and column names you have.

    Why? 

    Why is it wrong to expose your SQL in the presentation layer?  What "rule of programming" is this breaking?

    and why don't you want your users to be able to see the sturcture of the underlying data?

    go



    If you practice N-tiered development, it's waaaay wrong.

    If you practice FAD and DWIT, it's perfectly fine.

    Can't figure out what FAD and DWIT is? Follow this link: http://weblogs.asp.net/alex_papadimoulis/archive/2005/05/05/405747.aspx
  • (cs) in reply to Sean Connery
    Anonymous:

    when I said its not that bad. But yes, CRUD in the query string by application design is bad, but by appropriate security, it does not make a difference (i.e. potentially damaging sql injection is avoided)


    While you can make the security system on the db work in the way you're proposing, it's still far less risky to expose the data through some sort of intermediate layer rather than just allowing arbitrary sql to be input into the system.  All it takes is one slip up setting the permissions to fsck you.
  • Sean Connery (unregistered) in reply to mizhi
    mizhi:
    Anonymous:

    when I said its not that bad. But yes, CRUD in the query string by application design is bad, but by appropriate security, it does not make a difference (i.e. potentially damaging sql injection is avoided)


    While you can make the security system on the db work in the way you're proposing, it's still far less risky to expose the data through some sort of intermediate layer rather than just allowing arbitrary sql to be input into the system.  All it takes is one slip up setting the permissions to fsck you.


    Thats true. In my application, I did not allow random sql, but a sql-like language that only understood select, various joins and comparison clauses.

    Then just to make sure, I gave the admins an app to lock down the database by default (and we shipped a locked down database, duh).

    In my case, requirements dictated this design. But I'm not sure about the OP. Which I said in my OP :)
  • (cs) in reply to mizhi

    ^^ NOTE: I am in no way endorsing Mr. Connery's method (or today's WTF for that matter), I'm simply saying that it can be done.  In the same way that you could use gotos to implement a for() loop: it's possible, but not recommended.

  • Sean Connery (unregistered) in reply to Rodyland
    Anonymous:
    Well, for my $0.02, if you want to give your users access to table for, for example, ad-hoc SQL or whatnot, you should create views on your tables and use them.  Much cleaner, much safer, much easier to maintain, all that good stuff, IMHO.


    Hehe, I did :)

    It was lost in the back of my head but this is all coming back to me.

    I'd really like to know how other people have implemented true ad-hoc query systems in applications that actually get shipped (not ones in their heads)
  • (cs) in reply to Sean Connery
    Anonymous:

    Thats true. In my application, I did not allow random sql, but a sql-like language that only understood select, various joins and comparison clauses.

    Then just to make sure, I gave the admins an app to lock down the database by default (and we shipped a locked down database, duh).

    In my case, requirements dictated this design. But I'm not sure about the OP. Which I said in my OP :)


    Ah.  So you did, in fact, create an additional layer between the raw sql and the user.  It just happened to look like sql.

    That's a huge difference between your approach and the wtf.

    (although, most people would've opted for store procedures, etc)
  • (cs) in reply to JamesCurran
    JamesCurran:

    This reminds me of a web page I saw recently.  I just followed a deep link from one site to another.

    It was an ASPX page, and the page crashed immediately upon viewing (apparently, someone had deleted the line in the C# code where the SqlCommand object is declared.).  But the important points were:

    .....

       2) A external users could see the error message and the ENTIRE source code to the page.

       3) A quick glance at the source shows that a SQL injection attack would be trivial.

    I email the site explaining the above (If you customers are explaining SQL injection to you, you need to have a talk with you development staff).  The page doesn't crash anymore -- I haven't tried to see if the injection vulnerability is still there...


    I have seen this many times.. normally by really smart people who think that renaming their include files to *.inc is a good idea when it has read access in a public html dir. This means that the files isnt parsed by the ASP/PHP parser and a "bad" dude can read it and find trivial injection attacks. Or find the SQL DB server's password on a server hosted at another location ..... The file is hidden until the server goes down or somebody puts a single quote in the query and it comes up with "error on line 1233 in file C:\server\thedailywtf\public_html\include\server_connected.inc could not connect to server".

  • (cs) in reply to Chris F

    Chris F:
    Basic separation of concerns is the rule it breaks.  The presentation layer is for presenting things.  The data layer is for data access.  It's so simple.

    If you practice N-tiered development, it's waaaay wrong.

    You're both just citing rules that you've been taught and that have been burned into brains.

    Perhaps folks are missing the point  I'm trying to bring up (or prefer instead to argue over the best way to implement passthrough SQL design techniques)  but .....

    I say it's a BIGGER WTF to not understand why we separate presentation and data layers than it is to break it.  Following rules without understanding them leads to bad code.  SO can anyone here explain why allowing users access to sending SQL directly to our database is a WTF assuming that proper security is enforced on the database.

     

  • (cs) in reply to El Duderino
    El Duderino:


    Chris F:
    Basic separation of concerns is the rule it breaks.  The presentation layer is for presenting things.  The data layer is for data access.  It's so simple.


    If you practice N-tiered development, it's waaaay wrong.


    You're both just citing rules that you've been taught and that have been burned into brains.

    [snip]

    I say it's a BIGGER WTF to not understand why we separate presentation and data layers than it is to break it.  Following rules without understanding them leads to bad code.

    I would be here all night if I had to explain the fundamental principles from which I derive every statement.  Don't mistake a lack of information given for a lack of understanding.

    El Duderino:
    SO can anyone here explain why allowing users access to sending SQL directly to our database is a WTF assuming that proper security is enforced on the database.

    Again, it violates the separation of concerns.  Specifically, it unnecessarily commingles the two concerns of user selection of abstract criteria and specified data access.  The only place (to my knowledge) this isn't a problem is when we are using a low-level, non-abstracted SQL worksheet or query designer application.

    In a system that is abstracted from the database (such as a system like Magic), the user is most likely selecting search criteria such as 'all tickets belonging to me', or 'all tickets with a priority of 5'.  Decomposing this information into raw SQL and then passing it back up to the layer in which it was received couples the data access method to the interface, and in many cases is an unnecessary layer traversal.  If some new process (such as a cache) is inserted into the data layer, we would have no recourse because the selections have already been decomposed and passed back up to the interface layer.  Furthermore, if the criteria selection page does not do any querying, it shouldn't be necessary for it to even have knowledge of the underlying data store.

    A better solution would be to transmit the user's selected options instead of the raw SQL.
  • vhawk (unregistered)

    The pain ... oh the pain ....  scary as hell

  • Sine Nomine (unregistered) in reply to Sean Connery
    Anonymous:
    I'd really like to know how other people have implemented true ad-hoc query systems in applications that actually get shipped (not ones in their heads)


    We have the GUI creating an object-based representation of the query, which is translated to SQL in the backend. Pretty nifty, since it lets us work on optimisation without affecting the end-user part of the design. Additionally, the representation is serializable so you can store the queries as shortcuts in the database. Of course, it doesn't have the full flexibility of true SQL, but enough for most users' needs.
  • (cs) in reply to El Duderino

    Why is it wrong to expose your SQL in the presentation layer? What "rule of programming" is this breaking?

    Because queries get constructed in the model layer. The display data should simply display the data given to it, and feed input back to the controller. The controller does domain level transformations on that data, and feeds it back to the model layer. If you have domain (i.e. controller) and database (i.e. model) level code in the display layer, it makes maintenance a nightmare, and effectively removes the possibiity of adding a new interface without a complete rewrite. MVC is your friend, don't torture it.

    and why don't you want your users to be able to see the sturcture of the underlying data?

    Come on, that has to be a troll, no?

    Users == the people who can see your application. This includes the subsets of people who are immensely dense, thus neither needing nor deserving a view on the structure lest they break it by accident, and those who will want to break your application for fun and profit; this latter subset should be given no information on underlying structure.

    The 'select credit_card, expiry from customers' example has already been given. If I see encoded sql in a query, I can probably reverse engineer or guess enough information on the database and its underlying engine to be able to brute-force a complete view on your schema. That, combined with an ability to inject SQL into your app, means I own (at least) your data. Combined with a database level security hole, I own your server, too

    So, if I'm your competitor, I can get access to, for example, your customer list with ease. Without you ever knowing anything about it.

    All one needs to do is find a part of the app that displays tabulated data, determine the correct number of columns to be selecting and inject your own SQL. It may take many hits to extract everything, but automation is the attacker's friend

    It's amazing how much information one can glean with just a perl installation, a fast net connection, a web browser and a little intelligence. Even without query strings in the request. I invite the reader to surmise how one would create a dump of all posts ever submitted to the daily WTF in an automated way.

    Simon

  • Justin (unregistered) in reply to Sean Connery
    Anonymous:
    Anonymous:
    Ytram:
    Sure, if the db user that was taking this raw SQL was limited to only read access, no harm could be done with URL manipulation.


    Sure.

    SELECT credit_card_no, credit_card_expires FROM customers;

    No harm done.



    Which is why you only give access to certain tables/fields.

    Sorry, no it isn't!  It's why you only give access to certain procedures/functions which provide a business API to the database.

    Justin.

  • (cs) in reply to John Bigboote

    LOL.

    I built a nice user interface for Magic myself. I've managed to get most of the things I wanted working (except auto-login). The database is hell though.

     

    Drak

  • Suomynona (unregistered) in reply to johnl
    johnl:
    The WTF I see most often is when people think the latest version of Windows is Win98!


    Now that's stupid. We all know that the latest version of Windows is WinME.

    Seriously, though, I think what you say doesn't disprove what WTFer means. Windows defaults to administrator access, and you have to create two new user accounts to change that. When you log in as root at SuSE Linux's graphical login prompt, on the other hand, you are greeted with a desktop image which shows cartoon-like bombs on a bright red background. It seems to say: There are brighter ideas than surfing as root.

  • (cs) in reply to Drak

    All you guys bitching about the the fact that end users should never see the database should get a grip with reality.

    It's really nice being all theoretical and academic and purist about things, and go on about n-tier and other fantastic things that mean nothing to the client. But the reality is - if a client has bought a piece of software from you for a couple of hundred K, then they will probably want to be able to do ad-hoc reporting on the database.

    And guess what! - the user creating the reports is gonna need to know your data dictionary and schema. Kinda helps then for when they use Crystal Reports or other tools to do what they want with the data they OWN. Yes, they own the data in their database, not you  the developer sitting in a darkened room a thousand miles away.

    That rant said - write access to the database should never be permitted except via the application, but let the user query the data all they want, and for god's sake don't put it in a URL available on the internet!

  • Suomynona (unregistered) in reply to Quinnum
    Quinnum:
    And guess what! - the user creating the reports is gonna need to know your data dictionary and schema. Kinda helps then for when they use Crystal Reports or other tools to do what they want with the data they OWN. Yes, they own the data in their database, not you  the developer sitting in a darkened room a thousand miles away.


    What does it matter who owns the database when everyone can 0wn it?

  • (cs) in reply to Suomynona

    Thank you Tufty, Sine Nomine and Chris F!  I was beginning to think I was the only one who saw the bigger WTF.

    Strangely enough everyone here jumped on the security concern when in fact the WTF is lack of orthagonal. design.  Change your backend?  Whoops, now you gotta change you front end too!

    A bit more esoteric than the interesting string manipulations that we saw yesterday but a nice illustration.

  • dave (unregistered) in reply to El Duderino

    Are you upset because it's YOUR code that was posted? 

    Anyway, please stop asking people on this forum for explanations to the painfully obvious, and go to the bookstore or your local library.  Read an introductory text on software development.  Or perhaps take a class on it at your local community college.  It will obviously be money well spent.

    -Dave

  • (cs) in reply to El Duderino

    Very interesting.....

    Firstly, tufty, while I agre with you on principle, the intelligence of your users depends greatly on what your application is.  If it's, say, a stock management system, which is used by normal people, fair enough.  But a software development-oriented tool would be used by, well, developers.  Assuming proper security, this isn't bad at all.  Worse would be to provide views that then don't provide the flexibility you need, because then the product is useless.  I'm still against plain text query strings for security reasons, though.  Encrypted strings would be better.

    Secondly, I'm increasingly of the opinion that everyone should do a mandatory three years' tour of duty in the world of Windows Installer.

  • (cs) in reply to Quinnum

    Quinnum:
    All you guys bitching about the the fact that end users should never see the database should get a grip with reality.

    It's really nice being all theoretical and academic and purist about things, and go on about n-tier and other fantastic things that mean nothing to the client. But the reality is - if a client has bought a piece of software from you for a couple of hundred K, then they will probably want to be able to do ad-hoc reporting on the database.

    And guess what! - the user creating the reports is gonna need to know your data dictionary and schema. Kinda helps then for when they use Crystal Reports or other tools to do what they want with the data they OWN. Yes, they own the data in their database, not you  the developer sitting in a darkened room a thousand miles away.

    That rant said - write access to the database should never be permitted except via the application, but let the user query the data all they want, and for god's sake don't put it in a URL available on the internet!

    I think the definition of the word "User" is causing confusion.  If you buy an accounting system with a backend database, the IT department and analysts might indeed wish to be aware of the database schema, and you could say they "own" the database and can do with it what they like.

    But all of the OTHER users using the system -- people entering AP transactions, filling in timesheets, running prepared reports, and so on -- they certainly have no business at all mucking around in the database. 

    Also, don't forget if you run a web portal in which your customers all log in and use it.  Should your customers -- who are all "users" -- be aware of your internal database schema and be able to view raw SQL code?  Or even random visitors to your site?

    When you expose raw SQL to *all* of the users then this is where the problem occurs.  Of course power users and administrators with the proper rights (from a business perspective, not a literal computer permissions perspective) should have whatever access to the products they own and administer that is necessary.

    However, even with that point of view, it is still preferable to provide some layer of abstraction between the actual internal workings of the system and the interfaces that even power users use. 

    What happens when you say "we own this database" and therefore write hundreds of reports and interfaces directly off of the database schema and then version 2.0 comes out later on that makes significant changes to that schema?   If the application provides a decent, flexible API to abstract the database, and keeps it consistent, then this doesn't occur (or the impact is hopefully minimal).  Note that even using views and stored procs as this layer can greatly help should the schema need to change, as long as these are kept consistent.

     

     

  • (cs) in reply to Sean Connery

    Anonymous:

    Thats true. In my application, I did not allow random sql, but a sql-like language that only understood select, various joins and comparison clauses.

    Sean -- you have slightly redeemed yourself with this clarification.  Hopefully now in retrospect you can recongize that you intially defended *raw SQL* being passed around which was visible/editable by all users, and not what you mentioned above.

  • (cs) in reply to El Duderino
    El Duderino:

    Chris F:
    Basic separation of concerns is the rule it breaks.  The presentation layer is for presenting things.  The data layer is for data access.  It's so simple.

    If you practice N-tiered development, it's waaaay wrong.

    You're both just citing rules that you've been taught and that have been burned into brains.

    Perhaps folks are missing the point  I'm trying to bring up (or prefer instead to argue over the best way to implement passthrough SQL design techniques)  but .....

    I say it's a BIGGER WTF to not understand why we separate presentation and data layers than it is to break it.  Following rules without understanding them leads to bad code.  SO can anyone here explain why allowing users access to sending SQL directly to our database is a WTF assuming that proper security is enforced on the database.



    Who said they don't understand?   You seem to be asking for EVERY post to turn into a lecture on basic orthogonal  design principles.  How dull.  We might as well explain the vastly complicated concepts of "breathing" and "walking" as well!

    I agree that following rules without understanding them is a horrible thing to do, but you seem to be equating a lack of an explanation with a lack of understanding.  Not only is it just plain wrong, but rather arrogant. 

    Oh, and if security is a TOP priority you shouldn't "assume" that anything is enforced on the database.  Of course, it rarely is...
  • (cs) in reply to tiro

    tiro:


    Who said they don't understand?   You seem to be asking for EVERY post to turn into a lecture on basic orthogonal  design principles.  How dull.  We might as well explain the vastly complicated concepts of "breathing" and "walking" as well!

    Great point, Tiro!

    Again, here's the rule of thumb: if you find that when you visit this website and look at the code posted, you more often than not think "what is wrong with this?", then that is a pretty good indicator that perhaps this might not be the right site for you.  

    A certain level of understanding of at least the basic concepts really needs assumed when we discuss the code examples, and it really gets off track when we spend more time defining these concepts rather than being amazed at the clever ways in which these programmers violate them.

  • (cs) in reply to Jeff S

    That's true, although quite often it does need defining.  A WTF in one case is a good system in another, depending on what the application does, what part of the system you are looking at, who's using it, and the limitations of the system it was developed with.  This is a WTF because it's an app designed (if I understand right) to allow remote access to issue lists - very useful for remote developers, etc.  That means it's accessible outside the network, posing a security risk.  Even if the user has appropriate restrictions, this *could* include sensitive information.  If the app was only accessible internal to the network, then it's not as bad.

    Similarly, an app that allows raw SQL queries is bad if the users who might enter those queries don't understand the database schema, but there are valid times when that is a good thing to do.

    I use Installshield, which allows you to save data as an XML file (it used to only allow binary format).  The advantage of an XML file is that when I check my project into source control, I can do a compare on it to see what I've changed.   It also means that the file is stored as a delta rather than having a whole new copy of the file.  Perhaps I shouldn't be able to do that, though, since this allows me to see the schema?

    Lots of things are WTF's when not taken in context.  To understand why something like this is a WTF, you need to understand how the application is used, and where this code is used.

    On the subject of layers, for most things I agree with you.  But OTOH I'm hardly going to turn a single-assembly (working in C#) simple utility which, say, exports a table from a database into a major application just to satisfy layer rules.  Again, context is important.

  • (cs) in reply to Jeff S

    Maybe I should point out that my first post on the subject started with :

    For the sake of discussion, I'll play the Devil's Advocate.

    I'm very familiar with design principles and thought I'd point out that no one else was even addressing what I thought was the more serious WTF.  Lack of orthagonal design should have been the first word out of people's mouth.  Even though the Security Model wasn't addressed by the post, it was what everyone started talking about.  Security concerns of passthrough SQL from the URL can be addressed just like any other security concerns -- by applying security.  But even a strong security model won't save them from the work required when they have to change their backend -- (It also won't keep people from sending in queries like:  <FONT face="Courier New" size=2>select * from very_large_table, very_large_table, very_large_table;)</FONT>

    Anyway, until I brought it up, no one was talking about it and I assumed that it was overlooked.  Clearly I underestimated the skillsets of complete strangers on the internet.  Or maybe my mind reading skillz aren't az l33t az otherz.

    Thanks for the lesson guys!

  • (cs) in reply to johnl

    On the subject of layers, for most things I agree with you.
    But OTOH I'm hardly going to turn a single-assembly (working in C#) simple utility which, say, exports a table from a database into a major application just to satisfy layer rules. Again, context is important.

    Yes, I agree. however, one might assume that if one is exporting data from a database, there is somewhere an app that is also accessing the database. And if that app is written in a 'tiered' or 'MVC' way, one's export might end up looking as simple as this (ruby / activerecord syntax)

    File.open("report.txt", "w") do |report|
  Customer.active_customers.each do |customer|
    report.puts "#{customer.name} : unpaid invoices" unless customer.unpaid_invoices.empty?
    customer.unpaid_invoices.sort{|a,b| a.issue_date <=> b.issue_date}.each do |invoice|
      report.puts invoice.reporting_details
    end
  end
end

    That's not much code, but I think you see where I'm going. You'll note that there's no need to 'access the database', as that's already provided in my nicely layered code.

    Note also that invoice.reporting_details doesn't have to be defined in the base level, as ruby is a dynamic language so I can add it at runtime in my report script. I like a dynamic language.

    Simon

  • (cs) in reply to El Duderino

    Anyway, until I brought it up, no one was talking about it and I assumed that it was overlooked. Clearly I underestimated the skillsets of complete strangers on the internet. Or maybe my mind reading skillz aren't az l33t az otherz.

    Or, just maybe, it had been overlooked and you were the first to notice.

    Although, generally, for something to be posted here, it's almost a given that there has been no orthogonal design. Or, indeed, design at all, such that most sane individuals would recognise it...

    Code fragments here are generally like onions. you peel off the outer layer of wtf-ery, and there's another one. and another. and another. they also make me cry.

    Simon

  • WTFer (unregistered) in reply to johnl
    johnl:

    WTFer:

    I think is similar to what happens with Windows security vs Unix security. It's better to close everything and start opening things little by little, instead of giving everyone administrator priviledges. The same applies for SQL is better to create your own secure interface than living sql open and then trying to close it down.

    Not sure what you mean here.  I'm going to assume that you're trying to suggest Windows has bad security because it allows users full access, then you can limit those users in certain ways.  Whereas with *nix you create a restricted user then grant access in certain places.  There is only one problem with this.  It's completely false.

    (Those of us who have actually set up a Windows box in the last few years can skip this bit while I explain it)

    You see, when you set up a Windows box, you get the option to create a number of users.  The installation sets up an admiistrator account (essentially the same as the root account in Linux), and then you create other users.  These can be of different types, ranging from "guest" (very few rights) through to "administrator".  You can also do this during the installation on XP.

    The WTF I see most often is when people think the latest version of Windows is Win98!


    Sorry, I did meant that but no so dramatically.. and windows was just an example.... I work almost exclusively on Windows, and haven't had a problem in my machines for years, but even in XP  the default setup is still administrator. I know it can be locked pretty tight and windows is moving in that direction. IIS is another example, they release a lockup tool because to many options were open by default. An unexperienced ASP could never know how many sharing protocols IIS can manage by default, so its better them to open them when they know about them and not leaving them open and waiting them for closing. My point is, in my opinion is always better granting privileges, than denying them because you never know what you could miss. If you consider sending SQL statements through the wire, I think is better to create your own APIs.
  • Sam (unregistered) in reply to tufty

    use LWP::Simple;

    use HTML::TokeParser; 

    $baseurl = 'http://www.thedailywtf.com/forums';

    $incrementor = 0;

    $newurl = $basurl.'/'.$incrementor.'/ShowPost.aspx';

    ...coding the rest is pretty trivial (make a loop and RTFM).  Though I'm unclear why getting all the posts is important...though the technique has helped me compile some pretty interesting lists (and makes me wonder why so few sites bother with robots.txt)

  • (cs) in reply to Sam

    Though I'm unclear why getting all the posts is important...

    It's not. What is important is to realise that even with a pretty tight interface, one can work outside the box to do things that the original app was not coded to account for. It seems mind-numbingly-obvious, but it takes very little to slip up and allow access to sensitive information through supposedly 'secure' channels. For example, this software has a protected forum that you're not allowed to browse, but an approach similar to the one outlined above would seem to be a reasonable first step to seeing if you could get access to the posts in it[1].

    This is why web developers need to be paranoid. The bits of your code that is exposed to the world (publically or not) will be probed, prodded, twisted, tortured and generally abused. If you were to put sensitive information on a server running "magic" on the public internet, I think you could safely assume that the information was as good as leaked. Remember, the hacker that does the most harm is the one you don't see : the one that's selling your information to your competitors. He will be stealthy, fast, and targetted.

    If you're not paranoid, you're dogmeat.

    Simon

    [1] Note that I do not condone hacking, I have no idea if Alex's site can be hacked, and no interest in doing so. It suffices me to know that I could probably do so if I so desired.

  • (cs) in reply to johnl
    johnl:
    On the subject of layers, for most things I agree with you.  But OTOH I'm hardly going to turn a single-assembly (working in C#) simple utility which, say, exports a table from a database into a major application just to satisfy layer rules.  Again, context is important.

    You don't have to turn simple utilities into major applications to have a good layered design.  A particular layer can be as thin as a single function if that's all that's necessary.

    tufty:
    [snip Ruby]

    A good example.  The topic of export applications yield some of my favorite interview questions because they benefit so clearly from a good layered design.  It's very easy to tell which candidates understand the most common design issues when they explicitly state that they will split their export into three or four basic functional areas.  What I look for is a module that models the domain of what is being exported, a module that translates the data source into this model, a module that exports this model to the target data format, and a service or controller that ties them all together.
  • (cs) in reply to Chris F

    Ok, I'm gonna keep this as short as possible.

    Firstly, tufty's ruby example works fine... as long as it's part of another system and will be deployed with that system.  If you're supposed to just be able to drop the utility onto a machine and export the database, then it needs to carry its dependencies with it (which might be other files), and then it starts to be a bigger app.  If it's meant to be completely seperate and unaffected by changes in your other projects, again, it needs its own stuff with it to access the database.  If it's not meant to have access to the rest of the system...  well, you get the idea.  And I'm talking about an app developed in, say, C#, a language which likes layering.

    My point is that layered design isn't always good design.  Having said that, I do like it.  I just recognise that there are valid situations where to use it isn't particularly good.  I'm also against creating layers out of single functions, myself.  You end up with ridiculously verbose code that is just hard to read.

    @WTFer.  Windows creates an admin user by default.  But then so does Linux.  On both OS's, when you create the user, you are allowed to set certain priviledges.  On Windows (I can't remember, but I think Linux is the same) you get some preset choices (guest user, restricted user, user, power user, admin user), but you can modify at a low-level the different rights (such as rights to a certain folder).  All users on Windows do get certain rights by default, but these are generally low-level until you get past the middle-level user stage.

    Damn, that wasn't short.

  • (cs) in reply to tufty

    tufty:
    Note that I do not condone hacking, I have no idea if Alex's site can be hacked, and no interest in doing so. It suffices me to know that I could probably do so if I so desired.

    You're telling me that you don't believe Community Server to be rock solid? What possibly could you base this on? Haven't you seen how great this software works for everything else?

     

  • Hank Miller (unregistered) in reply to johnl
    johnl:

    You see, when you set up a Windows box, you get the option to create a number of users.  The installation sets up an admiistrator account (essentially the same as the root account in Linux), and then you create other users.  These can be of different types, ranging from "guest" (very few rights) through to "administrator".  You can also do this during the installation on XP.


    In theory anyway.   Those who have tried to set someone up as anything other than administrator have learned that few applications will run correctly anymore.   Most apps, even from Microsoft, write to administrator only areas of the system (mostly registry).  

    I've been told that experts can spend a lot of time in various tools until they figure out exactly what each program is doing, and then give the users access to do only that.   I'm not an expert, I'm a unix guy who can figure out computers better than my friends, so they have me do the hard problems on their machines.  

    On my unix systems I can predict in advance if a program will need root access.  I don't worry about installing untrusted users (as in they will make a mistake, not to be confused with activly hostile users who try to break the system) on my unix systems because I don't have to give them rights to allow them to do everything I do on my computers day to day.    Contrast that to Microsoft Windows, which requires several hours of an expert administrator's time everytime you want to install some new program.

    No unix game needs root, many Microsoft Windows games need administrator.    There is no excuse for this requirement.

  • (cs) in reply to Hank Miller

    "In theory anyway.   Those who have tried to set someone up as anything other than administrator have learned that few applications will run correctly anymore.   Most apps, even from Microsoft, write to administrator only areas of the system (mostly registry).  Most apps, even from Microsoft, write to administrator only areas of the system (mostly registry)."

    Well, if you know what resources that application uses, you can increase the access on that particular resource, or tweak the configuration of the app.

    The main requirement for administrative rights is during the installation, and there's a case that you shouldn't be able to install apps without administrative rights anyway.

    And don't get me started on games!  [:P]

  • Sean Connery (unregistered) in reply to Sine Nomine
    Anonymous:
    Anonymous:
    I'd really like to know how other people have implemented true ad-hoc query systems in applications that actually get shipped (not ones in their heads)


    We have the GUI creating an object-based representation of the query, which is translated to SQL in the backend. Pretty nifty, since it lets us work on optimisation without affecting the end-user part of the design. Additionally, the representation is serializable so you can store the queries as shortcuts in the database. Of course, it doesn't have the full flexibility of true SQL, but enough for most users' needs.


    Sweet, thats what I did. Though there was no optimization.
  • (cs) in reply to anonymous
    Anonymous:
    Might I suggest BugZilla?
    Bugzilla is a WTF too. Try RT if you want a free one with a decent codebase.
  • Matt S Trout (unregistered) in reply to JThelen

    "Funny that you mention user credentials in the query string. When a piece of software was turned over to my current shop from the contractor, that was actually how the credentials were passed to the report server from the app server. Plain, clear as day text in the query string. Not even being on fire is that bad if you ask me."

    I actually implemented that on one occasion because the vendor actually told us it was the only way of doing it. I didn't have time to argue with them, so I got written confirmation from management and implemented it anyway.

    I still feel dirty.

  • Whisker The Mad (unregistered) in reply to mizhi

    You could also wash your car with a sandblaster.  I mean, I've dealt with bad code, but I always assumed that it was because some schlep didn't know any better.  I never imagined that it was because they thought that violating basic programming principles was "the right way."

    Thank you for enlightening me.

Leave a comment on “Do You Believe In Magic?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article