Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Recently I found a hardware device that can prevent bot attacks by changing html DOM elements on the fly The details are mentioned here
The html input element id and name and also form element action will be replaced with some random string before page is sent to client. After client submit, the hardware device replace its values with originals. So the server code will remain on change and bots can not work on fixed input name, id.
That was the total idea, BUT they also have claimed that this product can solve the man in the browser attack.
http://techxplore.com/news/2014-01-world-botwall.html :
Shape Security claims that the added code to a web site won't cause
any noticeable delays to the user interface (or how it appears) and
that it works against other types of attacks as well, such as account
takeover, and man-in-the-browser. They note that their approach works
because it deflects attacks in real time whereas code for botnets is
changed only when it installs (to change its signature).
Theoretically is it possible that some one can prevent the man in the browser attack at the server?!
Theoretically is it possible that some one can prevent the man in the browser attack at the server?!
Nope. Clearly the compromised client can do anything a real user can.
Making your pages more resistant to automation is potentially an arms race of updates and countermeasures. Obfuscation like this can at best make it annoying enough to automate your site that it's not worth it to the attacker—that is, you try to make yourself no longer the ‘low-hanging fruit’.
They note that their approach works because it deflects attacks in real time whereas code for botnets is changed only when it installs (to change its signature).
This seems pretty meaningless. Bots naturally can update their own code. Indeed banking trojans commonly update themselves to work around changes to account login pages. Unless the service includes live updates pushed out to the filter boxes to work around these updates, you still don't win.
(Such an Automation Arms Race As A Service would be an interesting proposition. However I would be worried about new obfuscation features breaking your applications. For example imagine what would happen for the noddy form-field-renaming example on the linked site if you have your own client-side scripts were relying on those names. Or indeed if your whole site was a client-side Single Page App, this would have no effect.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Tumblr allows users to edit the HTML and CSS of their blogs through a Templating system. In fact, it even allows users to include their own external scripts into their pages. Doing this obviously opens a lot of security holes for Tumblr; however, it's obviously doing fine. What's even more interesting is how Tumblr's team managed to do all these through a LAMP Stack before.
One thing that I found out through pinging different Tumblr sites is that the blog sites are dispersed through multiple servers.
Nonetheless, hacking the root of just one of those servers could compromise a ton of data. Furthermore, while some could argue that Tumblr may just be doing manual checks on each of its blogging sites, it still seems pretty risky and unpractical for Tumblr's team to do so because of the amount of data that Tumblr has. Because of this, I think there are still some aspects that checking manually hasn't covered yet, especially in terms of how Tumblr's team filters their user input before it enters their database.
My main question: How does Tumblr (or any other similar site) filter its user input and thereby, prevent hacking and exploits from happening?
What is Tumblr.
Tumblr is a microbloggin service, which lets its users to post multimedia and short text blogs on their website.
Formating and styling blog
Every blog service lets its user to edit and share the content. At the same time they also let their users to style their blog depending on what type of service they are providing.
For instance, A company blog can never have a garden image as its background and at the same time a shopkeeper can never show a beach image; unless they are present at that place or include such objects in their work.
What Tumblr. does
Well, they just keep checking the files for any error!
As a general bloggin platform. It is necessary to allow the users to upload and style them blogs. And at the same time it is a job for the company to keep the control of how their service is used!
So Tumblr. keeps a great note on these things. They also donot allow to upload files that infect the system, and are well-known to delete such accounts if anything fishy is caught!
Tumblr. allows the users to upload files and multimedia that is used to style the blog. They used a seperate platform where to save all such files! So when you upload it, it does not get executed on their system. They access it from the server or from the hard drive which these files are saved on and then provide you with the blog that includes those files.
What would I do
I would do the same, I would first upload and save the files on a seperate place, where if executed they donot harm my system if are infected by a virus. Not all the users upload virus. But once they do, you should use an antivirus system to detect and remove the virus and at the same time block that account.
I would have let the users to use my service, now its user's job to upload content and its my job to prevent hacking.
All this stuff (HTML/CSS/External scripts) does not run on Tumblr machines. So to them it does not matter. One is responsible for the stuff that runs on your own PC. As to Javascript it lives in a sandpit
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
There are lots of ways to create a login form for web apps and most of them are flawed one way or the other:
Passwords are transmitted/saved as clear text
The login dialogs are subject to XSS attacks or SQL injection
Is there an example or tutorial how to create a secure login form?
I agree with Carlos about lack of "perfect" secure system, not only for login, but for any other component. The only thing to do is to minimize risks by following best practices, but always keeping in mind that total safety doesn't exist, so your question is quite difficult to answer, although there are some good examples out there nothing is perfect, security is a very fast evolving topic.
For me the main things to solve are:
-Data transmission: The user is always going to type a password and this has to be sent to your system before it was processed, so there is a high risk of being intercepted if you are using an open channel. To solve this you MUST use transport the data over an encrypted channel (SSL), no other way unless you drop the common password (for example using one-time use tokens, or delegating the authentication to a third party, like Facebook connect or openId). See "How to Make a Secure Login Form with SSL"
-Input Sanitation: To avoid XSS and SQL Injection consider any input that comes from a client as a potentially risk point, therefore you have to perform validation against anything that comes form outside --> doc. Another good practice is never use the inputs directly on queries, use as bind variables in prepared statements or stored procedures.
-Password Storage: Password should always be stored encrypted with a one way hash algorithm, so even in the case of someone accessing your DB, there is no way to recover the original passwords. Also use techniques as Salting, Hashing multiple times, etc... Also be careful to choose an algorithm that is not weak or outdated (like MD5), which can be broken by brute force easily with the increasing CPU power.
-Infrastructure: Have your machines, OS, frameworks, libraries always updated to avoid bugs and 0 day attack. Any system today is enormously complex, and the system is as secure as it weakest component.
-Other Things to Consider: Review your security policy regularly to see if needs to update anything, implement password policies (expiration, reuse, etc...), log access, use monitoring tools for your systems, etc etc etc
And after all that, you can still be sure that if someone has enough time and resources, your system will fall.
Your question, can't be that agnostic, and must be divided in your two main concerns:
Transmitting passwords in the clear.
Xss, Sql injection.
No system will be declared secured per se, but you can try your best to minimize the risks by using proven concepts.
So let's say you have the chance to design your own "secure system", what do you need?
At minimum you will need a basic set of tools:
Client side data encripting: (Javascript here, i think you will find lots of info of how to send your data in data 64 or something like that, remember you are searching for one way or two way encription)
DB Encription: (One way-two way encription, but never save passwords in the clear)
SQl injection: (mysql_real_escape_string() comes to mind).
Every language has some sort of protection built in, it is when building large projects that sometimes we may forget to sanitize some querys
I repeat no system will ever be declared secure, however you can add some other security measures as in:
access_tokens = timed-strings that allow to validate user login.
captcha_after_few_intents = you should add this definitely.
block_account_after_few_trys = pain in the * for users, but definitely worth it.
login_token = store a token unique for that user, and use it in all GET/POST transactions
SSL
From Bank Security:
Automatic gsm devices that generates RANDS and access_tokens valid only for a short time.
mouse keyboard: evitates keyloggers
random_access_question:
check_random_account_country_change = let's say user is from albany and next day he logs in from south america, that should maybe raise a flag to your system.
I'm sure you will find plenty of advice somewhere, but remember you at end will end talking html, and some js, your main defense is on the server side, so be good, or be good at it.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
From what I understand, you have to enter in all of your usernames and passwords into Mint, so I assume they are actually logging into your bank account and scraping the resulting screen to put this data into a form that Mint and others use.
How do they actually simulate the keypresses and mouse clicks? I assume banks don't like it when they do this - how do their scrapers avoid detection?
I'm pretty sure they don't simulate clicks, etc. In the end, any data that ends up on a user's page is transmitted in a response to a request. If you can figure out how to construct a valid request and then how to parse the response, you'll have the data you want.
As far as I could gather after using Yodlee for quite a while, they deal with sites in two major ways: the sites they have official agreements to work with and the sites they don't have official agreements with. For the first category of sites they, most often, have agreed upon APIs for getting the data. For the sites in the second category they reverse-engineer layer 7 communication protocols and data structures (a.k.a. screen/html scraping).
The way I understand it, Yodlee uses the OFX specification to access banks' financial information.
http://www.ofx.net/
For the banks that don't implement OFX, they use custom screen scrapers, which must constantly be updated when banks change the information that's displayed on their site.
I don't know Yodlee so i simply assume it's like "sofortüberweisung.de" where you give a 3rd party your bank login data (and depending on what you do even a valid TAN) and thus trust them not to abuse it and additionally break your bank's security regulations ("NEVER GIVE YOUR YOUR PIN/TAN").
They most likely simulate what a browser would do. As web-based banking interfaces are usually just HTML/JavaScript everyone can look at the client-side code and do whatever it does with a custom program. Since those actions are not done in a malicious way, actions which require e.g. a TAN or a CAPTCHA to be solved can be simply forwarded to the legit user who will then enter the necessary TAN or solve the CAPTCHA.
Nonetheless to say, it is really bad to use services like that. While they most likely won't do anything bad you cannot know it for sure. And your bank is damn right if they don't refund you anything if you ever get scammed by such a service.
Another solution which would be perfectly safe (as long as you are not concerned about a 3rd party knowing about your financial status etc.) would be the yodlee company making contracts with major banks allowing them to access your data after you've authorized it through some way (you can already do that on pages like Twitter - I'd never do that for bankign though but technically it wouldn't be hard to realize something like that). That would be clean and secure as it would not involve "screen-scraping" or customers entering their banking login data anywhere but on their bank's website. But I believe no bank does something like that and in my opinion that's good as there are way too many people out there who are far too trustworthy and we all know how many information they give out on Facebook & Co. Now imagine a facebook<->bank integration... M.Zuck.'s wet dreams which hopefully never become true... And even if it's not Facebook.. There'll always be companies who want people's personal data and enough people giving them out; especially if it's easy and looks secure ("I have to confirm it on MY BANK's page. so it MUST be safe - it's supported by MY BANK").
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Let's say I have designed s very important system, and this system costs thousands dollars. I want to protect my system with a serial number as I know crackers will try to edit the binary code to bypass the serial number.
I have read about using a checksum function and apply it over my binary code and check the value if changed, but again, we are talking about a condition a cracker can avoid by editing the code.
My question is: what's the most used technique to protect important programs?
I have yet to see a "protected" digital product that had not been cracked pretty quickly after its publication (or in some cases, before its publication). Sorry, but it's the reality. You have to get the revenue by making a good product. Most of those who want to use it and can afford, will pay.
There will be a few dickheads, but that's life. You better be kind towards the legit users of your software and not bully them with weird copy protection attempts that don't work anyway.
If your app is working offline, whatever checks you do (check sums, serial code validity, etc), do them often, repeating verification code, in many routines of your software. Obfuscate your code, to make reverse engineering a more difficult task, and, if you have the possibility, implement an online check, part of the core functionality of your app residing on your server, and being serviced only to those installations that you have checked server-side for valid license key. Associate the license key to some form of unique identifier of the hardware the app is running on, and if you check online, have statistics concerning the IPs that make the verification request: if you encounter more IPs trying to verify the same license key, contact the buyer and approve a list of IPs they usually log on from, whilst blacklisting any other until specific request from them, either by mail or by phone.
The most used technique is serial numbers. But your customers will have access to the code, so they will be able to bypass your serial number check, no matter how much work you put into obfuscating it.
However, if you can provide your software as a subscription-based or one-time-payment web application, then people will not be able to do this. Whether this is feasible or not depends on the type of application you're writing.
I would always recommend to build a custom software protection before applying any kind of commercial protector such as a Packer.
In any case just a serial validation and a checksum check are not going to keep crackers away.
I would recommend you to visit my new blog www.anti-reversing.com and take a quick look at the anti-piracy tips & tricks page just to have an idea about what I am talking about.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Regarding Agile development, what are the best practices for testing security per release?
If it is a monthly release, are there shops doing pen-tests every month?
What's your application domain? It depends.
Since you used the word "Agile", I'm guessing it's a web app. I have a nice easy answer for you.
Go buy a copy of Burp Suite (it's the #1 Google result for "burp" --- a sure endorsement!); it'll cost you 99EU, or ~$180USD, or $98 Obama Dollars if you wait until November.
Burp works as a web proxy. You browse through your web app using Firefox or IE or whatever, and it collects all the hits you generate. These hits get fed to a feature called "Intruder", which is a web fuzzer. Intruder will figure out all the parameters you provide to each one of your query handlers. It will then try crazy values for each parameter, including SQL, filesystem, and HTML metacharacters. On a typical complex form post, this is going to generate about 1500 hits, which you'll look through to identify scary --- or, more importantly in an Agile context, new --- error responses.
Fuzzing every query handler in your web app at each release iteration is the #1 thing you can do to improve application security without instituting a formal "SDLC" and adding headcount. Beyond that, review your code for the major web app security hot spots:
Use only parameterized prepared SQL statements; don't ever simply concatenate strings and feed them to your database handle.
Filter all inputs to a white list of known good characters (alnum, basic punctuation), and, more importantly, output filter data from your query results to "neutralize" HTML metacharacters to HTML entities (quot, lt, gt, etc).
Use long random hard-to-guess identifiers anywhere you're currently using simple integer row IDs in query parameters, and make sure user X can't see user Y's data just by guessing those identifiers.
Test every query handler in your application to ensure that they function only when a valid, logged-on session cookie is presented.
Turn on the XSRF protection in your web stack, which will generate hidden form token parameters on all your rendered forms, to prevent attackers from creating malicious links that will submit forms for unsuspecting users.
Use bcrypt --- and nothing else --- to store hashed passwords.
I'm no expert on Agile development, but I would imagine that integrating some basic automated pen-test software into your build cycle would be a good start. I have seen several software packages out there that will do basic testing and are well suited for automation.
I'm not a security expert, but I think the most important fact you should be aware of, before testing security, is what you are trying to protect. Only if you know what you are trying to protect, you can do a proper analysis of your security measures and only then you can start testing those implemented measures.
Very abstract, I know. However, I think it should be the first step of every security audit.
Unit testing, Defense Programming and lots of logs
Unit testing
Make sure you unit test as early as possible (e.g. the password should be encrypted before sending, the SSL tunnel is working, etc). This would prevent your programmers from accidentally making the program insecure.
Defense Programming
I personally call this the Paranoid Programming but Wikipedia is never wrong (sarcasm). Basically, you add tests to your functions that checks all the inputs:
is the user's cookies valid?
is he still currently logged in?
are the function's parameters protected against SQL injection? (even though you know that the input are generated by your own functions, you will test anyway)
Logging
Log everything like crazy. Its easier to remove logs then to add them. A user have logged in? Log it. A user found a 404? Log it. The admin edited/deleted a post? Log it. Someone was able to access a restricted page? Log it.
Don't be surprised if your log file reaches 15+ Mb during your development phase. During beta, you can decide which logs to remove. If you want, you can add a flag to decide when a certain event is logged.