EPTThe Big Programming Thread - Page 701
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
|
Deleted User 3420
24492 Posts
| ||
|
Manit0u
Poland17397 Posts
On January 15 2016 06:23 travis wrote: edit: how do i turn off button hover in bootstrap What do you mean? Do you want to disable the button? http://getbootstrap.com/css/#buttons-disabled | ||
|
Deleted User 3420
24492 Posts
I guess technically I could do that by just changing the hover color to match the normal color lol which is what I will do anyways, so I am designing this website, just seeing what I can make and as I play around and it slowly starts turning into something I like, I realize that more and more it is slowly just turning into the front page of reddit. I can't seem to help it. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
spinesheath
Germany8679 Posts
On January 16 2016 04:03 Nesserev wrote: What are some of the recommended books regarding testing and TDD? I was thinking of getting my hands on one of Kent Beck's books, but was told that Kent Beck's style is a little bit too Billy Mays, and that I should stay away from any book that even reeks of the word Agile, cause it'll be just another sales pitch. I quite liked TDD by example, not sure what's to hate about Kent Beck's style. | ||
|
Manit0u
Poland17397 Posts
On January 16 2016 04:03 Nesserev wrote: What are some of the recommended books regarding testing and TDD? I was thinking of getting my hands on one of Kent Beck's books, but was told that Kent Beck's style is a little bit too Billy Mays, and that I should stay away from any book that even reeks of the word Agile, cause it'll be just another sales pitch. Just a few pages back: http://chimera.labs.oreilly.com/books/1234000000754/index.html | ||
|
aksfjh
United States4853 Posts
On January 13 2016 01:19 berated- wrote: +1 - rewrites are definitely.. interesting. The problem I have with them most of the time is the fallacy that it will be easier to understand, combined with the failure to understand the current product. If you can't dive in and figure out the current one, I've never been quite certain how one thinks they will rewrite it and get it correct. I would say the biggest problems with rewrites is the attempt to do too much under the guise of "rewrite." In his specific example, The new project was supposed to be all OOP, SOA, TDD and stuff that is way too much work to put under the umbrella of a single project/rewrite. Doing each individual thing listed (OOP, SOA, TDD) is an undertaking and full team effort all on its own. You should take each one as a step to improve the current product, and if you can't do that, then you have no place doing a rewrite using those techniques/paradigms.The only time I can see doing a complete rewrite like that is if you literally have a team of developers/programmers practically sitting around doing nothing or otherwise need a large project to undertake while your normal team is also underwhelmed with maintenance. Something that, if you threw a bunch of resources into and it failed, it would suck but it wouldn't ruin your product/brand. | ||
|
Animzor
Sweden2154 Posts
+ Show Spoiler + SDL_Rect Sprite::getRect() const { return rect; } I assume set functions are used to change the object, so it seems reasonable to always use const in get functions. | ||
|
Nesserev
Belgium2760 Posts
| ||
|
bangsholt
Denmark138 Posts
https://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development Read it and I like it, because it takes small steps and doesn't assume you know things, so it's all explained thoroughly. | ||
|
solidbebe
Netherlands4921 Posts
On January 16 2016 04:03 Nesserev wrote: What are some of the recommended books regarding testing and TDD? I was thinking of getting my hands on one of Kent Beck's books, but was told that Kent Beck's style is a little bit too Billy Mays, and that I should stay away from any book that even reeks of the word Agile, cause it'll be just another sales pitch. If you are interested in some articles/blogs by Bertrand Meyer and my software quality and testing professor: + Show Spoiler + Bertrand Meyer. "Applying Design by Contract". IEEE Computer, 1992. http://se.ethz.ch/~meyer/publications/computer/contract.pdf Bertrand Meyer. "Seven Principles of Software Testing". IEEE Software, 2009. http://se.inf.ethz.ch/~meyer/publications/testing/principles.pdf "Line Coverage: Lessons from JUnit". http://avandeursen.com/2012/12/21/line-coverage-lessons-from-junit/ "Test Coverage: Not for Managers?" http://avandeursen.com/2013/11/19/test-coverage-not-for-managers/ "Learning from Apple's #gotofail Security Bug." http://avandeursen.com/2014/02/22/gotofail-security/ "Beyond Page Objects: Testing Web Applications with State Objects." http://queue.acm.org/detail.cfm?id=2793039 | ||
|
Cynry
810 Posts
I'm looking to secure all the client input when he calls server sided logic, for inserting document into a db for exemple. I've type checked everything and made sure only the fields I required were present, but the possible issue comes from how I've done it. Basically I receive the following args : the name of the function to execute, related data, optional target for the function. For most functions it's a one step process, check first, then execute, no problem. But in some cases, like inserting a document, the related data contains a whole object representing the document to create, and the process happens in 2 phases. First, I make sure there is a document of type Object in the data, but I don't check what's inside. Then inside the create function, I check each of the document's objet's fields before copying them to the db. I'm worried because *some* stuff happens inbetween. Nothing interacts with the document object's fields before they are checked, but I still wonder if there's some security hole possible in this scenario.. | ||
|
Manit0u
Poland17397 Posts
On January 18 2016 08:34 Cynry wrote: Any web hacking knowledge around here ? I'm looking to secure all the client input when he calls server sided logic, for inserting document into a db for exemple. I've type checked everything and made sure only the fields I required were present, but the possible issue comes from how I've done it. Basically I receive the following args : the name of the function to execute, related data, optional target for the function. For most functions it's a one step process, check first, then execute, no problem. But in some cases, like inserting a document, the related data contains a whole object representing the document to create, and the process happens in 2 phases. First, I make sure there is a document of type Object in the data, but I don't check what's inside. Then inside the create function, I check each of the document's objet's fields before copying them to the db. I'm worried because *some* stuff happens inbetween. Nothing interacts with the document object's fields before they are checked, but I still wonder if there's some security hole possible in this scenario.. Could you be a bit more specific? What do you mean by 'user calls server-side logic' and what is the document? Is it just some text? Fields from some form? Uploaded file that you save as binary data? If you're worried about stuff like SQL injection or XSS I can give you some hints. It really boils down to what programming language/framework you're using for the most part. Most modern frameworks already come with enough built-in security but if you've written your web application in pure PHP from scratch you can be in a world of hurt if you don't know what you're doing. You'd be surprised how many people still use deprecated database connection methods... Some general hints for your regular form -> object -> db path: 1. HTML validation - html5 provides you with pretty nice validation for some form fields out of the box. This prevents the browser to even submit the form with invalid data (email, password, numbers come to mind - some fields can also have regexp validation). 2. Form validation - this is done server-side, after the form is submitted but before the object is created. 3. Object validation - your getters and setters can also include a layer of validation. 4. Proper SQL - this is the last part. You should design your database properly with correct field types, default values etc. Then you should also make sure that your queries are constructed properly (using literals for text, query parametrization etc.). | ||
|
bangsholt
Denmark138 Posts
Also make sure you do a proper check of return values and catch exceptions if applicable, so that you don't leak information about your systems. | ||
tofucake
Hyrule19148 Posts
| ||
|
Cynry
810 Posts
Could you be a bit more specific? What do you mean by 'user calls server-side logic' and what is the document? Is it just some text? Fields from some form? Uploaded file that you save as binary data? There are methods in meteor, which are the functions the client side of the app calls to do any modification to the database. From the client app the server receives data as JSON objects, coming from forms. But the same methods can also be called from console with who knows what as arguments, and there lies a key point of securiy in meteor, making sure you're receiving proper data in methods. We're using some kind of ORM, so all fields are enforced, default values set etc. I'm in fact fairly confident that it's now quite secure, and I was just wondering about the particular case I mentionned. I'll add some code tomorrow to explain further. | ||
|
aksfjh
United States4853 Posts
You should also investigate all known vulnerabilities of your parsers. Some JSON and XML parsers have been known to be vulnerable to kinds of injections and behave strangely to malformed or unusual formatting. Your project is probably fine from a design perspective if you have enough sense to actively think and ask about security. | ||
|
Manit0u
Poland17397 Posts
On January 18 2016 11:48 Cynry wrote: Of all the terms I didn't understand (literals, query parametrization, prepared statements) I'm not sure which ones are SQL related... All of them  Literals, query parametrization, prepared statements - that's what most ORMs can handle for you as they do it automatically most of the time (if you're using DBMS like H2 you can even disable literals and force people to use parametrized queries and prepared statements, ORM or not). You can even do it without ORM but it requires more work. https://en.wikipedia.org/wiki/Prepared_statement http://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/ | ||
|
Deleted User 101379
4849 Posts
On January 18 2016 11:48 Cynry wrote: Oh yeah we're working with meteor, so all javascript and mongodb. Of all the terms I didn't understand (literals, query parametrization, prepared statements) I'm not sure which ones are SQL related... There are methods in meteor, which are the functions the client side of the app calls to do any modification to the database. From the client app the server receives data as JSON objects, coming from forms. But the same methods can also be called from console with who knows what as arguments, and there lies a key point of securiy in meteor, making sure you're receiving proper data in methods. We're using some kind of ORM, so all fields are enforced, default values set etc. I'm in fact fairly confident that it's now quite secure, and I was just wondering about the particular case I mentionned. I'll add some code tomorrow to explain further. If you are working with MongoDB you don't have to worry about the SQL stuff. MongoDB works with a completely different API and structure, so almost none of the SQL things with prepared statements and such applies. However, what you need to keep in mind: 1. If you get documents from outside that you want to write to the database, verify that it is valid. If the document comes straight from the frontend, people can write whatever they want into your database, including new keys and such. Make sure that every document only contains the data you allow and that that data is valid. Don't rely on any frontend verification. I explicitly copy the values over to a new object instead of using the object I get from the outside to make sure it's clean, though that adds overhead and another place to maintain the data structure. 2. Validate queries. If you just do $query = ["username" => $username, "password" => $password]; you run the risk that users manipulate the frontend to have $password be something like ['$exists' => true], and suddenly they can log in as any username. This is the closest to SQL injection and easy to overlook. 3. For all deletions, verify that the filter is correct so you don't accidentally delete your whole collection. Depending on the API there are separate methods for deleting just one and deleting any amount of documents. 4. Verify that you are accessing the correct collection. Don't accept any collection selection that comes from the frontend, always take it from a configuration or some constant. 5. Make sure authentication is enabled. The default MongoDB installations don't have authentication enabled and it's easy to forget to enable it when you are just working on the programming side. Make sure user accounts only have the access they need and not a tiny bit more, which means separate users for administration, backups and the actual server<->DB communication. | ||
|
Cynry
810 Posts
On January 18 2016 23:57 Morfildur wrote: 1. If you get documents from outside that you want to write to the database, verify that it is valid. If the document comes straight from the frontend, people can write whatever they want into your database, including new keys and such. Make sure that every document only contains the data you allow and that that data is valid. Don't rely on any frontend verification. I explicitly copy the values over to a new object instead of using the object I get from the outside to make sure it's clean, though that adds overhead and another place to maintain the data structure. We don't copy the values to a new object, but we type check every fields before actually using them using some kind of ORM, and make sure they are the only one received. Would that be enough ? Copying whole object would require some implementation of a deep extend function, I'd rather avoid that.. Everything else is duly noted, didn't even knew there was an auth to enable in mongo... Thanks a lot ! | ||
| ||
