Slashdot Mirror


Mobile Devs Making the Same Security Mistakes Web Devs Made in the Early 2000s (bleepingcomputer.com)

Catalin Cimpanu, writing for BleepingComputer: Mobile app developers are going through the same growing pains that the webdev scene has gone through in the 90s and 2000s when improper input validation led to many security incidents. But while mobile devs have learned to filter user input for dangerous strings, some of these devs have not learned their lesson very well.

In a research paper published earlier this year, Abner Mendoza and Guofei Gu, two academics from Texas A&M University, have highlighted the problem of current-day mobile apps that still include business logic (such as user input validation, user authentication, and authorization) inside the client-side component of their code, instead of its server-side section. This regretable situation leaves the users of these mobile applications vulnerable to simple HTTP request parameter injection attacks that could have been easily mitigated if an application's business logic would have been embedded inside its server-side component, where most of these operations belong.

96 comments

  1. Very legitimate reason for this by Anonymous Coward · · Score: 0

    For heavily used apps, leaving the validation client side can result in substantially lower hardware requirements on the server side.

    1. Re: Very legitimate reason for this by reanjr · · Score: 4, Informative

      If you're doing validation to help the user, that might be fine. But if you're validating for correctness or assuming data has followed all your validation rules, then client-side validation is worthless.

    2. Re:Very legitimate reason for this by glenebob · · Score: 2

      TFA was apparently written specifically with you in mind.

    3. Re:Very legitimate reason for this by Hognoxious · · Score: 1

      If only there was a way to do the validation in both: on the client side for fast response and on the server for security. That'd be just dreamy!

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    4. Re:Very legitimate reason for this by MouseR · · Score: 1

      Well, that's what we do in our group (info withheld—not here to pander our things).

      We use a file name validator object we pass around to a multitude or places in the app that enforces format of such things as file names.
      But MITM attacks wouldn't be prevented by this and the first line of defence is server side: it will not accept unvalidated inputs.

      Ease of use is enhanced by having client side verification telling the user exactly what's wrong with their input.

    5. Re:Very legitimate reason for this by jellomizer · · Score: 1

      You should always have both.

      Client Side and Server Side validation.

      Client Side, can do a lot of work, tell you what is wrong, make sure lengths are correct get rid of bad characters...
      The Server Side still needs to be the last line of defense. If there something wrong, wrong length bad characters, missing fields. It should reject the entry of the data into the system and at least return a general error saying it didn't do it.

      In terms of hardware requirements. Most validations take such a small amount of processing, that you will not notice it on the hardware, and the end user may get a fraction of a millisecond deference in wait.

      The excuse that it will effect hardware requirements on the server, may work for your boss. But technically it is just an excuse to be lazy.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    6. Re: Very legitimate reason for this by jittles · · Score: 2

      If you're doing validation to help the user, that might be fine. But if you're validating for correctness or assuming data has followed all your validation rules, then client-side validation is worthless.

      Agreed. Someone can always sniff your APIs and try to attack your web interface, but you ought to validate inputs on client side just for the sake of your customers. The client app should not trust the user to input data correctly and the server should not trust the client to do so either. Don’t trust anyone. It saves your customers waiting for an error response from the server if you can easily determine they input something incorrect.

    7. Re:Very legitimate reason for this by gweihir · · Score: 4, Insightful

      Indeed. Those that think reducing the need for server hardware this way is acceptable should be banned for life from coding anything. It does not get much more stupid than this when security is a factor.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    8. Re:Very legitimate reason for this by gweihir · · Score: 1

      Anybody competent does it. Seriously.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    9. Re:Very legitimate reason for this by Anonymous Coward · · Score: 1

      That leads to things like Node.js, where you can use the "same" programming language on both the client and server side. Of course you then end up with developers who only know javascript, and they go around trying to recreate everything in javascript, or they create some clunky Framework that "solves" the validation problem by pushing complex libraries onto the client, which normally requires extensive testing yet it never seems to happen.

      The truth is that client validation and server validation have a small area of overlap. You can check the data type on the client, and you absolutely have to check the data type on the server, and you can check field lengths and do sanity checks, and you can use some of the same code to do this on both the client and the server. But server side validation requires additional code to get the errors back to the client, so it is already a different beast. Then you might need to add some monitoring and logging tools on the server side, useful to detect penetration attempts. Pretty soon it doesn't matter that you are using the "same" language for both client and server coding, because the idioms are different and require different strategies.

    10. Re: Very legitimate reason for this by jellomizer · · Score: 1

      The client side is like a screen door. You may be able to lock it, but locking the screen door is just telling people to use a different door, not actually doing anything to stop them from getting in, especially if you leave the door behind it open.

      Javascript can be stopped or changed on the client.
      Apps that do a system call to a server can always be packet sniffed and traced.

      Programs need to be designed in a way the developer will not be able to get into the application.

      --
      If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    11. Re: Very legitimate reason for this by Anonymous Coward · · Score: 0

      This. Beat me to it.

    12. Re:Very legitimate reason for this by Wrath0fb0b · · Score: 2

      Even more to the point, the two should use the same exactly library for validation so that there is never a disagreement about what constitutes valid input. Failing that, one of the two should be designated as a 'reference implementation' and have the source & unit test suite shared so it can be reimplemented exactly.

      You'd be surprised how often mobile/server teams don't even have read-only access to each other's actual source repository. It's like someone imagined that keeping them in dark would somehow be beneficial.

    13. Re:Very legitimate reason for this by sootman · · Score: 1

      Are you dumb, or trolling? AC, so I'll guess troll. You ALWAYS need server-side validation. Bad actors won't use the client -- they will use telnet, curl, or a million other tools. Client-side validation will save some load on your server from honest people like honest mistakes -- no need to round-trip that data just to find that they left the '@' out of an email address, or missed a digit in a credit card number -- but for the ACTUAL data, you can ONLY trust the server to do the validation before saving.

      What you're saying is like saying "we don't need police to enforce traffic laws -- we have signs saying what drivers should and shouldn't do."

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    14. Re:Very legitimate reason for this by Anne+Thwacks · · Score: 1
      Node.js, where you can use the "same" bugs on both the client and server side.

      FTFY

      --
      Sent from my ASR33 using ASCII
    15. Re:Very legitimate reason for this by jeff4747 · · Score: 1

      First, validation is not exactly a large amount of server-side processing. Assuming your server is not a 386-SX

      Second, you could do validation in both places. The local rejection would speed up the responsiveness to your users since there's no round-trip involved, and you'd also block various attacks that are sent to the server from something other than your client....especially since your server validation needs to cover things your client-side does not.

      But that means keeping two sets of validation code in-sync. Which is harder than just doing it on the server.

    16. Re:Very legitimate reason for this by jeff4747 · · Score: 1

      Client Side, can do a lot of work, tell you what is wrong, make sure lengths are correct get rid of bad characters...
      The Server Side still needs to be the last line of defense

      Your server needs to run the client-side validation too. A request may not have come from your client, or your client may have been compromised such that it does not run the validation.

    17. Re:Very legitimate reason for this by SQLGuru · · Score: 1

      The article didn't indicate that they attacked the APIs.....they merely looked at the signatures. Just because the API looks like it can be hacked, doesn't mean it doesn't perform the necessary validations server-side ALSO.

    18. Re:Very legitimate reason for this by Anonymous Coward · · Score: 0

      The article didn't indicate that they attacked the APIs.....they merely looked at the signatures. Just because the API looks like it can be hacked, doesn't mean it doesn't perform the necessary validations server-side ALSO.

      What are you talking about? An API automatically validates inputs for you? Seriously, where did you get the idea from? You, who are a programmer, must explicitly do it, not API. The API may have a function/method to aid you in validation, but it will NOT validate any kind of inputs for you. Don't be silly.

    19. Re:Very legitimate reason for this by Anonymous Coward · · Score: 0

      Even more to the point, the two should use the same exactly library for validation so that there is never a disagreement about what constitutes valid input.

      No, both sides don't need the "same exactly library" for validation. However, both sides need "the same" validation rules. The reason is that often times the server and client side can be implemented using different technologies.

      The way you said sounds like you only use a web frame work which deals with both display and the server, and a validation needs to go through the server. This is not a good idea. Client side validation should be done via local validation (e.g. Javascript) for speed and less traffics to the server. An interactive web site does not need to be restricted to justthe way you are thinking.

    20. Re:Very legitimate reason for this by Wrath0fb0b · · Score: 1

      The reason is that often times the server and client side can be implemented using different technologies.

      Indeed. If they are using different technologies, they should just share the set of test vectors used for unit testing.

      But in the case where it's a client/server application both written in C#/Java/..., then indeed there's no reason that both sides cannot use the exact same library.

    21. Re:Very legitimate reason for this by Hognoxious · · Score: 1

      Well. there's something to be said f or consistency.

      Imagine you have a two-tier system where then front end's done in some retarded offshoot of VB and the backend's done on some retarded version of perl? Where's the bug?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  2. Mobile devs assume security where there is none by Anonymous Coward · · Score: 0

    Just because your average user is dumb doesn't mean the attackers are too.

    1. Re:Mobile devs assume security where there is none by gweihir · · Score: 1

      The average attacker is dumb. But one non-dumb one can do a lot of attacks, especially with the help of automation. You have been competently attacked when you only notice months or years later or not at all.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  3. Dear lord by Anonymous Coward · · Score: 0

    How out-of-this-world do you have to be to include business logic on the client-side. Seriously... who in the hell is employing your stupid ass?

    1. Re:Dear lord by Anonymous Coward · · Score: 0

      While unacceptable for authorization, it is perfectly acceptable for input validation if the server side is also enforcing the same rules.
      Nobody likes waiting for network round-trips just to be told they made a typo. You, like most developers, may be unaware of this latency because you work in the server room chained in a cage.

    2. Re:Dear lord by Anonymous Coward · · Score: 0

      How fucking stupid do you have to be to listen to vague precepts about "separating business logic" from specific physical hosts rather than thinking about components which have separation of concerns?

      Also what the fuck do you think "business logic" is - is it somehow related to "that which your app is actually fucking for rather than your cock-tastic JavaScript library for reticulating splines"?

  4. Sorry, these are not growing pains by BerkeleyDude · · Score: 1

    These are idiot developers.

    1. Re:Sorry, these are not growing pains by gweihir · · Score: 1

      Well, since it is a growing body of incompetent developers, it is at least a growing pain. The ever more complicated field of half-assed "frameworks" and intransparent mechanisms used makes things worse. The sheer amount of over-complicated, non-intuitive, "magic" technology used in the web and app fields is absolutely staggering and will never be secure.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Sorry, these are not growing pains by Darinbob · · Score: 1

      If there's one constant in software development, it's that nobody learns from the past. It's not a new problem either.

  5. Client Side AS WELL AS Server Side by Jason+Levine · · Score: 4, Insightful

    There's nothing wrong with Client Side validation. It lets you prompt the user to correct their mistakes. Of course, this client side validation shouldn't be trusted when the data gets to the server-side. You need to check it on the server side also. Client Side verification has it's place in any good web application.

    --
    My sci-fi novel, Ghost Thief, is now available from Amazon.com.
    1. Re:Client Side AS WELL AS Server Side by ctilsie242 · · Score: 4, Insightful

      You need both. Client side is for sanity checking, just so the obvious security issues don't make it to the server and take up server resources (bandwidth, etc.). For sense of security, everything needs to be checked at the server side, as -nothing- should be trusted. Sorry, Bobby Tables.

    2. Re:Client Side AS WELL AS Server Side by gweihir · · Score: 3, Insightful

      Client-side: Usability.
      Server-side: Security.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    3. Re:Client Side AS WELL AS Server Side by Anonymous Coward · · Score: 0

      I've seen some pretty shitty client side validation. Often, I'll cut and paste something in and because I didn't type it, the validator fails. I miss the days when every field didn't have some bullshit AJAX tied to it. Square won't let me cut and paste the amount of money I want to send, because it *needs* to have an animated "$" and "." going on.

    4. Re:Client Side AS WELL AS Server Side by Anonymous Coward · · Score: 0

      That's just shitty code/implementation. That could have in any language.

    5. Re:Client Side AS WELL AS Server Side by MobyDisk · · Score: 2

      Much of that is inconsistency with HTML5 events: both in terms of the spec but also the implementation. For example, some controls have "click" events that are really "focus" events. Some have "click" events and "changed" events and others have both. This is why something might work with a mouse but not with a keyboard, or with a mouse but not a touch screen, or in one browser but not another.

    6. Re:Client Side AS WELL AS Server Side by Tablizer · · Score: 1

      Much of that is inconsistency with HTML5 events: both in terms of the spec but also the implementation.

      I would suggest ditching direct reliance on HTML5 until they get the glitches out. Let other shmucks be the guinea pigs.

      It took about 15 years to get pre-5 HTML (mostly) right, or at least predictable enough to work around its warts. I don't expect 5 will be significantly quicker.

      People fear keeping up with the Joneses so much that they follow the Joneses off cliffs. There's a reason I kick the Joneses off my lawn...and the Kardashians.

    7. Re:Client Side AS WELL AS Server Side by MobyDisk · · Score: 1

      I apologize, I didn't mean to imply that these problems only applied to HTML5. These problems still apply to pre-5 HTML as well. Really, this has been a problem since JavaScript's inception.

    8. Re:Client Side AS WELL AS Server Side by Anonymous Coward · · Score: 0

      The title of this article should really be “Server-side devs continue to make the same mistakes,” as it seems the mobile devs are actually doing things correctly while the server-side devs are the ones making the mistakes.

      Perhaps the assumption is that mobile app devs are also building their own backends. I’ve never met someone who can competetantly build both types of applications. You are either really good at one or the other, or you suck at both.

  6. Trust the client implicitly by Anonymous Coward · · Score: 0

    How about apps that trust the client implicitly?

    Yes I would like to change the passwords to everyone's account. Thank you server for honoring my request!

  7. Not Just Mobile Apps by neo00 · · Score: 1

    I don't think Web developers necessarily learned the lesson very well. Javascript-heavy (client-side JS) web apps with insecure RESTful backend also suffer from the same issues. I'm seeing a lot of those recently.

    Hasn't Panera Bread just recently suffer from a similar issue?

  8. License sotware engineers like actual engineers by llamalad · · Score: 2, Interesting

    It's funny how the media speaks of "software devs" like they're a cohesive body of professionals.

    In fact it's largely a bunch of people straight out of a coding bootcamp in over their heads with titles like "senior full stack developer" who think they're 10x rockstars because they can code Hello World.

    Managers love these folks because they work for peanuts + inflated job title. Need someone to cut corners to meet a deadline? Or to take some unethical business idea and build it into software? These are your guys.

    Find me someone who's worked his ass off getting licensed to practice their profession who's willing to put their livelihood, license, and professional liability insurance premiums on the line to save a couple bucks here and there.

    It's time for software to mature like other niches have- plumbers, electricians, structural engineering, for example. You DIY your projects around the house until you burn it down or the building inspector condemns it, and you should be able to do the same with your own computing hardware until you let the blue smoke out of it or it simply grinds to a halt under a malware infestation. But if folks are going to build apps for money they should be certified and accountable for ensuring their work meets reasonable standards.

    1. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      Google's executive in charge of security for that last decade (lcamtuf) didn't even have a bachelors. Your ridiculous "licensing" requirements would just keep geeks like him out, and lazy ass exam cramming Indians in.

    2. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      More government regulation? Great Idea!

    3. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      Licensing is more than just studying for an exam. It means putting your career on the line if you produce a shoddy / unethical, etc. product.
      It means taking responsibility for your actions.

    4. Re:License sotware engineers like actual engineers by avandesande · · Score: 1

      Licensing drives up salaries it will never happen.

      --
      love is just extroverted narcissism
    5. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      Sounds like a great way to push college costs even higher! As an education industry bureaucrat I fully support this!

    6. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      Nah, lynch mobs are more fun and the whole community gets to participate!

    7. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      So when the NSA tells you to put in a backdoor and later some Russians expose it, you get to lose your career, or move to China? Great Idea.

    8. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      No thanks. You're a faggot, and I don't need a licence to certify that, faggot.

    9. Re:License sotware engineers like actual engineers by HornWumpus · · Score: 1

      A PE would be professionally responsible to tell his boss: 'No, that would be insecure, can't do it.' The NSA wouldn't hire software PEs.

      I bet the NSA doesn't have lawyers on their hacking teams, because they carry extra responsibilities, they are a liability.

      They're there, but 'no nothing, see nothing', not even if you have apple strudel.

      --
      John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    10. Re:License sotware engineers like actual engineers by llamalad · · Score: 1

      You're picking things apart starting too high up in the stack.

      Does the government require buildings be built with secret back doors or faulty locks (so the occupants' security measures can be easily bypassed by anyone who knows the trick) or that building material manufacturers make bricks and lumber to shoddy specs so that new holes can be poked through structures at their whim?

      Why, then, should it be able to require that software on which peoples' lives and livelihoods depend be similarly compromised?

    11. Re:License sotware engineers like actual engineers by jeff4747 · · Score: 1

      Find me someone who's worked his ass off getting licensed to practice their profession who's willing to put their livelihood, license, and professional liability insurance premiums on the line to save a couple bucks here and there.

      Doctors and Lawyers exist. And they go through extremely lengthy and difficult licensing/education regimes. And they provide plenty of examples of people who did exactly what you claim they would not.

    12. Re:License sotware engineers like actual engineers by bill_mcgonigle · · Score: 2

      That's what ratings are for - your app store is more effective than any state licensing board. Though to be fair, liability should not be able to be waived with an EULA.

      Anyway, software design isn't at all like structural engineering. Gravity is consistent. Winds have a 100-year maximum, and you can build a seismic safe building anywhere if you want to pay for it and avoid outlier risks.

      With software, you have a building. The earth may suddenly turn to quicksand, your building may be attacked by dinosaurs, the people in the building are usually trying to set it on fire, and the people who own it will never spend one cent on fixing any problems that appear. That and meteors.

      There are heuristics for how to deal with these problems, but they're not entirely known at this point. AI testing might be one tool that will help us along, but please stop trying to pretend that software development is just another branch of engineering. "I wish X were better so X is just like Y, and by golly the government needs to regulate that" is just ... so derp. Let's solve the problems instead, over time.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    13. Re:License sotware engineers like actual engineers by Solandri · · Score: 1
      The vast majority of ratings are given by people even more clueless than the developers. It's basically the same problem as elections in a democracy - they've devolved into a popularity contest, where the winner is simply who can manipulate their public image via the media and advertisements, to most appeal to enough voters to get elected.

      What's needed is some unbiased pool of experts who can evaluate software, and give it their stamp of approval that it's passed attacks along known vectors like SQL query buffer overruns. Sort of a UL label for software packages.

      The alternative is licensing programmers so only ones who've received a certain education and passed a test of competency (e.g. they know about SQL query buffer overruns, and how to avoid them) are allowed to write software. This isn't as robust though because even competent programmers can have a bad day and make a mistake. In structural/mechanical engineering, this is offset by having multiple engineers inspect each others' work and signing off on it. Only when all have signed off is the design ready for production. That could work for software too, but as you point out the scope of possibilities is much larger with software, increasing the likelihood that all the programmers assigned to review some code may miss the same problem.

      With software, you have a building. The earth may suddenly turn to quicksand, your building may be attacked by dinosaurs, the people in the building are usually trying to set it on fire, and the people who own it will never spend one cent on fixing any problems that appear. That and meteors.

      Nobody is denying that software is different from physical design. But look at DNA. Babies heads don't explode just because the pregnant mother ate something that gave her a stomachache. Software can be designed robustly. The reason the "earth may suddenly turn to quicksand" in software is because the code you've written for "earth" is not robust and can be cajoled into doing things you don't expect (like turn to quicksand). So it's still a programmer's fault - the problem is just in the "earth" code rather than in the "building" code.

      The "people trying to set the building on fire" problem is a great example of a way software could be improved. People do try to set buildings on fire. As a result, we've got a bunch of fire codes added to building design. The architect and structural engineer aren't allowed to just design the building any way they want. They're forced to contemplate the situation - "what if a fire breaks out?" And design the building to withstand that scenario. Likewise, if programmers were forced to contemplate the situation - "what if we suffered a buffer overrun exploit?" perhaps they would design their software to be more resistant to damage such an exploit could cause. Instead of all your code simply accepting whatever value for command messages passed between them, maybe they'll also communicate the maximum length they expect such strings to be. And when one piece of code sees another subroutine passing it a string which is longer than that subroutine says should be the maximum length, it knows something isn't right and can refuse to execute that string as a command. If all code did this, then buffer overruns would be impossible because anyone writing code would be forced to check for buffer overruns in their new code, if they wanted that code to work reliably with other code.

      The biggest challenge to writing robust software isn't sloppy code. That can be countered by good education, good coding practices, and rigorous testing. The biggest challenge is the possibility of previously unknown exploits coming to light. When we build a building, we're relying on knowledge and experience gained over thousands of years as to how the ground and building materials behave. Nearly all the weird corner cases have already been found.

      Software OTOH has only been around for a few decades (if you exclude programmable sewing design machines). We are still finding weird corner cases, whose discovery can turn a previously accepted-as-safe coding practice into a dangerous one.

    14. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      It's time for software to mature like other niches have- plumbers, electricians, structural engineering, for example. You DIY your projects around the house until you burn it down or the building inspector condemns it, and you should be able to do the same with your own computing hardware until you let the blue smoke out of it or it simply grinds to a halt under a malware infestation. But if folks are going to build apps for money they should be certified and accountable for ensuring their work meets reasonable standards.

      I see. So you want a guild. And unions. I don't want to live in your fascist paradise.

      Improve your skills and come fight in the market.

    15. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      still happens to this day in construction, don't know if you've seen the self-insulating formwork (ICF), people used it for a few years and realized alot of problems with it like the concrete not being uniformly distributed and air pockets developing where the mix was too dry or not vibrated enough. Stucco is not insured in Canada (EIFS) as a building designer I can't specify it (must put proceed at own risk warning) because it'll delaminate due to freeze/thaw cycles within 1-5 years if not installed properly, the thing is, our buildings are constantly falling apart, there is no perfect building, just like software, there are some robust examples and then theres mud huts , it's a question of economy like every design discipline.

    16. Re:License sotware engineers like actual engineers by Anonymous Coward · · Score: 0

      Find me someone who's worked his ass off getting licensed to practice their profession who's willing to put their livelihood, license, and professional liability insurance premiums on the line to save a couple bucks here and there.

      Licensing and/or certificate are overused and overrated these days. They used to be something to demonstrate your profession. Nowadays, they are just to milk people for money. The only thing you can use them is their name but not what they test these people for.

  9. No Matter. AI fixes everything! by Anonymous Coward · · Score: 1

    The singularity AI will fix all that... BIGLY! Just dont try to buy a cake.. its against our beliefs to sell YOU anything.... FREEDUMBS 4 ALL!

  10. License engineers have the power to tell thereboss by Joe_Dragon · · Score: 1

    License engineers have the power to tell there boss NO THAT IS UNSAFE.

  11. Re:License engineers have the power to tell thereb by Anonymous Coward · · Score: 0

    Yet most engineers (outside of Civils, because it matters in that world) aren't licensed engineers, just people with engineering degrees.

  12. Well yes, because that's a new "generation" of by Casandro · · Score: 1

    people. Mobile apps are now the area inexperienced people will start writing their first public code. Before that it was web design and before that it was writing Windows desktop applications.

    Some of those people will then grow up and most likely leave that field, just as the mobile app environments are as shitty as the web design environments or the Windows desktop application ones.

  13. Presumptious by Junta · · Score: 1

    This presumes that web devs don't make these mistakes anymore.

    They make this sort of mistake all the time. The difference is that any big, recognizable name that failed to fix this ultimately failed for one reason or another. Look at smaller sites or internal services at companies that are home grown, they are still chock full of this stuff.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Presumptious by Anonymous Coward · · Score: 0

      This presumes that web devs don't make these mistakes anymore.

      Hah. I still see lots of sql injection errors on websites.

      Last week I saw the code for date validation of a user's input. Instead of using the internal date validator of the language they were using, they checked if the user's input contains two slashes. If it contains two slashes (eg 06/04/2018) then it must be a valid date.

      Sigh.

    2. Re:Presumptious by Anne+Thwacks · · Score: 1
      Was that the website where I posted a submission dated 35th of February 1866?

      You don't need Perl for that. Even PHP can do it!

      --
      Sent from my ASR33 using ASCII
    3. Re:Presumptious by maglor_83 · · Score: 1

      It also presumes that the mobile devs are writing the backends. Otherwise how is it the mobile dev's fault that the backend isn't validating data?

  14. Mistakes Web Devs Made in the Early 2000s... by asylumx · · Score: 3, Insightful

    Newsflash, webdevs still make these same mistakes. Often times there is little or no distinction between a "web dev" and a "mobile dev" in reality.

    1. Re:Mistakes Web Devs Made in the Early 2000s... by gweihir · · Score: 1

      Still the same incompetents that have no business coding anything connected to the Internet.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Mistakes Web Devs Made in the Early 2000s... by Anonymous Coward · · Score: 0

      Still the same incompetents that have no business coding anything connected to the Internet.

      Still, here we are, and we're going nowhere. DreamWeaving our way through input forms all day long...

  15. Cretinization of coding by gweihir · · Score: 4, Interesting

    More and more coders. Still the same (very small) number of people that can learn to code well. What do you expect? And no, coding well is not something everybody can learn. Might as well claim that anybody can be a PhD level Mathematician or a competent brain surgeon. Not so, not so in the least. And that utterly mistaken and completely unfounded belief is at the root of the problem.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  16. Truth by darkain · · Score: 1

    This is absolutely true. The easiest way to see this is to connect your phone through a captive portal which injects content (such as ads) into web pages. Then watch as they start showing up in apps instead! And if you think this is just bottom-tier, b00by devs, think again. For the first two years or so of Instagram existing, this was an issue. I only discovered it on accident one time when using in-flight WiFi, and had the airline's advertising at the top of my Instagram feed inside of their Android app. Since the Facebook acquisition though, things have tightened down quite a bit, but this just goes to show that it doesn't matter what scale an app is, oversights and fuckery will happen.

  17. Alternate reality by Anonymous Coward · · Score: 0

    Which one do the meta developers live in where a mobile device is always connected to the internet to make this distinction?

    To be fair, even if input checking is being done client side (which should happen for consistency of experience and performance reasons), it should still be done server side.

  18. Re:License engineers have the power to tell thereb by HornWumpus · · Score: 1

    You'll find clusters of PEs everywhere there are lives hanging on mature engineering. Aircraft, Automotive, Power, Navel as well as Civil and others I'm no doubt forgetting.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  19. Re:License engineers have the power to tell thereb by jbengt · · Score: 1

    You can't usually get a building permit without licensed engineers' stamps for structural, mechanical, and electrical. (Sometimes only an Architect's stamp is required, and for simpler jobs, maybe only a contractor's license.) However, the majority of the engineers doing the actual work are not licensed, but are rather working "under the direct supervision and responsibility" of the licensed engineer. This often means the person stamping the drawings has only a vague knowledge about the details of the design. Because of that, I've often said that a PE is a license to hire other people to do the work - but, of course, that's an exaggeration.

  20. Relevant by CodeHog · · Score: 1
    --
    Fat, drunk, and stupid is no way to go through life, son.
  21. Idiots by Anonymous Coward · · Score: 0

    People are dumb. What did you expect?

  22. Better yet by fred911 · · Score: 1

    Stop forcing mobile users to download your "app" in order to use services and product (VENMO!).

    --
    09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  23. Re: by Anonymous Coward · · Score: 0

    Having more regulation is required if we start to care about reliability of software systems. Currently, phone lines (landlines) have a government mandated quality of service, of 5x9s per year. That reliability is disappearing as VOIP is used more, since ISPs don't have any uptime guarantee.

    The main blocker is the rise in pay that would occur due to less qualified workers, if professional licensing was required. The big tech companies have done everything to keep the wages as low as possible and creating fake licensing standards doesn't seem beyond their capabilities.

  24. eh by buddyglass · · Score: 1

    ...inside its server-side component, where most of these operations belong.

    Particularly with mobile, it often makes sense to validate both places. Avoid a network call if you can.

  25. Doomed to repeat history by Anonymous Coward · · Score: 0

    If you've learned a lesson and don't write about it, and those lessons never get included in any curriculum or training. Then of course we're going to see people repeating the same mistakes. Don't assume that different industries automatically share information with each other.

    Just like you don't see plumbers and electricians sharing information, you won't see much exchange between web developers, mobile developers, device driver developers, etc.

  26. Server lag by farble1670 · · Score: 1

    two academics from Texas A&M University, have highlighted the problem of current-day mobile apps that still include business logic (such as user input validation, user authentication, and authorization) inside the client-side component of their code, instead of its server-side section.

    Maybe they want their app to be responsive and not spin waiting for the server to respond with "invalid input".

    1. Re:Server lag by jeff4747 · · Score: 1

      Maybe they should be validating in both places. That way you get responsiveness on the client and security on the server.

  27. Missing The Forest by BlueStrat · · Score: 1

    ...For the trees.

    For heavily used apps, leaving the validation client side can result in substantially lower hardware requirements on the server side.

    There's a much more fundamental reason; Human Nature.

    In general, the same type of people will approach the same type of problem in a similar way, including all the attempts at short-cutting, offloading, etc etc.

    One can observe this phenomenon writ large in history, as people fall for the same ideological/political promises of Utopia again and again every few generations. A pioneering rock band of the 1960s called "The Who" had a famous song named "Won't Get Fooled Again" in which they summed this phenomenon up with the line; "Meet the new Boss, same as the old Boss". (BTW, if you've never heard The Who, do it. Do it now. Read comments later. Thanks optional but welcome :) )

    Strat

    --
    Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
  28. Re:License engineers have the power to tell thereb by bill_mcgonigle · · Score: 2

    And yet buildings fall down and airplanes fall apart mid-flight.

    I'll compare Linus's competence with that of a PE any day. Neither are perfect, but some magic certificate wouldn't make Linus* any better at what he does.

    * or any other quality software developer

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  29. Re:License engineers have the power to tell thereb by Darinbob · · Score: 1

    But most companies have a few PEs around to do the necessary sign-offs. The other engineers just need to know who these people are.

  30. Feels to me that it should be both by Anonymous Coward · · Score: 0

    Feels to me that it should be both...

    Do client side validations to avoid invoking the server whenever the user sends something even if it's not valid, and do server side validation to sanitize the client side data, ensure it's not erroneous or hostile...

  31. About a year behind by Anonymous Coward · · Score: 0

    This was found out by that guy who found a pizza app that did client-side credit card validation.

    This is why a 4-year program for software development beats a 4-week coding bootcamp - you learn about the history of the discipline, and some of the reasons why things are done certain ways. You have the time to learn the right way to do things, as opposed to the current trendy way.

  32. Web devs still inept by pubwvj · · Score: 1

    Web developers are still doing a bad job. They fail to filter out unnecessary characters and reject perfectly reasonable input. Telephone numbers are a classic web dev fail. All of these should be valid:
    (508) 999-1010
    1-508-999-1010
    5089991010
    508-999-1010
    and more.

    Credit card numbers, dates and others are also major fail points.

  33. Those who do not know history are doomed to repeat by Anonymous Coward · · Score: 0

    it.

  34. Re:License engineers have the power to tell thereb by Hognoxious · · Score: 1

    You'll find clusters of PEs everywhere there are lives hanging on mature engineering. Aircraft, Automotive, Power, Navel

    Surely that last one is the province of MDs?

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  35. Similar outcome due to similar incentives by gotan · · Score: 1

    Implementing secure protocols takes development time and knowledge. Time equals money: either more developers are needed or more development time (i.e. the shiny new product/version comes out the door later).

    When eye candy sells better than some footnote about security in an advert, then guess which qualifications will be in demand from developers and which parts of a project will get more development resources allocated (time, qualified developers)?

    OTOH the costs of even a major security blunder is a bit of bad press that'll soon be superseded by the next big story.

    Now imagine you're the controller for the project, what would be your recommendations with respect for allocating resources in development or qualifications demanded when hiring new developers?

    --
    "By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
  36. Devs STILL making bad choices by Anonymous Coward · · Score: 0

    So, developers are STILL making bad design choices - this is news somehow? LOL SMH

    This is what happens when we have thousands of people becoming developers for the money, with no real passion for it...

    You want quality code and good designs, hire people that love what they do, and give them time to do it. It's not at all mysterious.

  37. Re:License engineers have the power to tell thereb by HornWumpus · · Score: 1

    Sorry.

    Punchline: Whore: 'That's not my navel, that's my colostomy.'

    Sorry, again. /Canadian

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  38. Re:License engineers have the power to tell thereb by HornWumpus · · Score: 1

    Linux is not a RTOS. Don't put it in 'human life critical' applications. There is such a thing as a PE in 'software'.

    No doubt Linus could build a RTOS, if he wasn't busy. But he hasn't yet. Likely wouldn't want to deal with the highly formal development process bullshit involved. Code checkin is like a square dance, no step of which involves 'cuss your partner'.

    There are stripped down distros that make the RTOS claim. But 'kernel mode drivers'.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
  39. Re:License engineers have the power to tell thereb by Hognoxious · · Score: 1

    Most people make the mistake the other way round.

    Naval gazing:. #Sitting on the dock of the bay ... watching the ships come in ... /#"

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."