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
I'm familiar with the term hacking. Although i never will become one of those hackers who scam people or make trouble, i believe it's an essential aspect any person who calls themselves a programmer must be able to do, as it is mainly about problem solving. But how does it work? When those people hack games or websites or the guy who hacked sony, do they use a programming langauge like ANSI C or c++ or assembly. Assuming they use a programming language, would it be possible to use javascript to hack in the same way you'd use any other language to hack. Furthermore, what do you have to do to be able to hack too. I just wanna know how it works, and the theory behind it all.
Hacking is unique every time. Exploiting some types of vulnerability doesn't require any particular language at all. Sometimes you hack whatever's there, in whatever language or form you find it. Sometimes it's necessary to automate part of the process, for example password cracking, for which you can use any language you like.
Cracking a commercial game commonly involves studying its disassembled machine code, figuring out which part does the CD or license check, and surgically replacing a few bytes of the code such that the check is skipped.
Hacking a website commonly involves discovery of some small clumsiness on the part of its developers, which allows viewing of should-be private data, or permits execution of custom code if it does not sanitize data properly. SQL injection is a common flaw when values sent to a database are not properly protected within quotes ("...") and so you can give values which break out of the quotes to execute your own commands. Cross-site scripting is a type of hack that uses JavaScript: If a website blindly takes parameters from the URL or submitted form data and displays them on the page without safely encoding them as text (worryingly common), you can provide a <script> tag for execution on that page. Causing someone to visit such a URL allows execution of scripted actions on their behalf. Code injection is also possible on the server side with PHP (or Perl, or similar), if sloppy code gives access to an eval-like function, or if server misconfiguration allows user-uploaded files to be interpreted by the server as scripts.
Hacking into an operating system or server program remotely may exploit bugs in its handling of network commands. Improper handling of malformed network commands can cause it to bungle user authentication checks or even to directly execute code provided in the network packet, such as via a buffer overflow.
Bugs in web browsers, plugins, and document viewers are similar. What should be safe types of file can be crafted with non-standard or broken values. If the programmer forgot to handle these cases safely they can often be used to escape the normal limits of the file type.
Viruses can also be slipped onto a machine via physical exchange of USB stick or CD or convincing someone to install virus-laden software. Such viruses are often written anew for each purpose (to avoid anti-virus software), but there are some common ones available.
Weak or badly implemented encryption can permit brute-force decoding of encrypted data or passwords. Non-existent encryption can permit wiretapping of data directly. A lack of encryption can also permit unauthenticated commands to be sent to a user or server.
Very obvious passwords, or unchanged default passwords, may allow simple guesswork to get into a system. Some people use the same password everywhere. This give websites the power to simply walk in to a user's email account and then take control of everything associated with it. It also means a password leak on one insecure website may be used to access accounts on many other websites.
And sometimes, "hacking" is social engineering. For example, imagine phoning up a junior employee and pretending to be someone in charge, to trick them into revealing internal information or reset a password. Phishing emails are a common, semi-automated form of social engineering.
Breaking into a system is rarely just one of these steps. It's often a long process of analyzing the system, identifying minor flaws and leveraging them to see if a useful attack vector is exposed, then branching out from that to gain more access.
I've never done it, of course.
There is a sort of "hacking" possible with javascript. You can run javascript from the adressbar. Try typing javascript: alert("hello"); in your address bar while on this website.
This way it it possible to hijack local variables, cookies for instance.
But since javascript runs on the client-side. People would have to use your workstation in order to gain access to your cookies. It is a technique that can be used to alter login data and pretend to be somebody else (if the site had been badly built).
If you really want to learn more about this there are some 'javascript hacking lessons' that can be found here: http://www.hackthissite.org/pages/index/index.php
Side note, there is a difference between hacking and cracking. Reference: http://en.wikipedia.org/wiki/Hacker_(programmer_subculture)
There are many exploits that can use javascript, probably the most well-known is going to be cross-site scripting (XSS).
http://en.wikipedia.org/wiki/Cross-site_scripting
To follow up on Michael's answer, it is good to know the vulnerabilities in software and how people exploit those vulnerabilities in order to protect against them, however hacking is not something you want to be known for.
For a start, you are actually referring to what is known as Cracking, not hacking. This question will surely be closed, however some brief observations ^_^
Cracking comes from a base level understanding of how computer systems are built, hence you don't learn how to crack/hack, you learn about computer engineering in order to reverse-engineer.
A popular platform for hacking is Linux; over windows for example as its open source so experienced programmers can write their own programs. Although experienced hackers can accomplish their goal on any platform.
There are many levels of hacking however, simple website security is worlds apart from hacking in to Sony and facing jail ^_^
You may have some fun on http://www.hackthis.co.uk though
It depends on many things, for example: how the html code is structured, for example, I don't know if you could hack an iframe, but a normal web-page would be relative easy to hack. Another security pitfall programmers usually do is passing sensitive information via url query-string, then you could get those pieces of data and submitting them wherever they are used in the html code.
There could be another details, but I don't figure them out right now.
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 3 years ago.
Improve this question
I’ve been looking into programming a website for a company (no data or information other than forms are on it) I’ve been looking at BlueHost as a hosting and the SSL secure feature for security, I don’t know any other securing or encrypting myself, will BlueHosts SSL be enough?
No. SSL only protects data in transit from interception by a 3rd party-- and there are many factors to consider on how SSL is implemented required to decide if it even does that satisfactorily.
There are many countless facets of security that you must consider beyond how to make sure that data doesn't get read by someone else while it is being transmitted between a browser and a server over SSL. Too many to elaborate on in a stackoverflow answer. To put it in perspective, when I deploy a system that contains any sensitive data (I work for a payment processing company, but "sensitive" covers a lot more than just credit card numbers), I have to answer around 800 questions on a security audit. Only about 30 of those questions relate to SSL and making sure SSL is implemented properly. Then a team of experts have to review the implementation of such a system, deliberate, and vote unanimously that it meets requirements. Even after all that, routine security audits find potential vulnerabilities that were overlooked and must be mitigated.
No. SSL by itself is not enough to consider a system "secure". If it has data that needs SSL, it almost certainly has more needs than just SSL.
First of all, you should have SSL. With that said, no, that is not enough.
So, what do you need? While it is true that there is a lot to cover, you clearly need to be pointed to the right direction...
As far as hosting provider goes, there are other features that you could be interested in:
Backups (although, you probably can roll a solution yourself)
Antimalware (although, if your site will not allow to upload files, it is less relevant)
DDoS mitigations.
I want to remind you that information security is not only confidentiality, it is also availability and integrity (and traceability).
Please set up a test enviroment, on a local server, make sure it works. You can do security audits on that before they go the production enviroment. Remember that the sooner you discover the bugs, the cheaper it will be to fix them... thus, you do not want to discover them in production.
Yeah, it is ok to not have HTTPS on the test enviroment. There is plenty to do besides that. And yeah, you should review the security in production too.
Ideally there will be team doing test, and among those tests they might look for potential vulnerabilities. There are also security scanners that can help with that.
However, you should be writing secure code to begin with. Right?
I have to tell you, the server-side is more relevant than the tagged HTML and jQuery. The golden rule is to not trust the client. Remember that request might not be coming from an actual browser (despite what the user agent might say). You must do validation on the server. Even though it is also a good idea to validate in the client (for a better user experience and to safe network capacity), client-side validations are virtally irelvant for security.
That is not the same to say that there are not things that can improve the security that can be done client-side. For example, figerprinting a client can be useful to detect when the client is coming from an unusual source for a given user, rising a red flag (a partial fingerprint is possible server-side). Also you can do mitigations for screen-recorders/keyloggers/shoulder-surfing.
There are also very specific cases where doing cryptography on the client makes sense. That is not the usual case. You probably do not need to do that. And in the odd case you do, please hire an expert.
Anyway, these are some things that developers often overlook (this is by no means a complete list):
Do not trust the client.
Validate all input.
Sanitize all output (considering where it is going to).
Use prepared statements on database access.
Specify character charsets (for HTML, server-side string manipulation, and both database storage and connections).
Do proper authentication and access control.
Store credentials properly.
Stay up to date with browser security features.
Use Cross-Origin Resource Sharing correctly.
Use HttPOnly cookies when possible.
Use a Service Worker and Web Cache properly.
Log errors instead of showing them to the client.
Have traceability for all modifications.
Also, consider two factor authentication.
You might also be interested in OWASP Top Ten project and OWASP Cheat Sheet Series. Note: These are not a security check list, and are not a replacement for a security audit. They aren't gospel either, however if you are not to follow them, let it not be because you are unaware.
Finally let me point you to Information Security Stack Exchange, a Q&A site dedicated to information security (hence the name) sister to this one.
Addendum: If you are not developing a web application, but setting up a content management system instead, then you must keep it up to date. Also, research and apply security hardening for whatever it is you are using.
Is there a way one call assembly language instructions in JavaScript ?
Basically i want to leverage AES-NI from a web browser .
One route is writing C bindings for AES-NI and then writing JS bindings to call C .
But is there a direct route ?
In short: no. Browsers do HTTP, that's it. You'll have to bridge the gap as you hinted yourself.
Browsers are, of course, as pointed out in comment below, much more these days than what they were 20 years ago. They can deal with a variety of content. But that does not take away the fact, that they are still intended to be user-level sandboxes, effectively creating a shielded playpen far away from the world below. After all, you wouldn't want some malicious script to wipe your personal files or grab hold of your chat logs or mail archive.
Pointing out the obvious: there are always security concerns when you cut the fence but I won't go off-topic here.
Having said that, there are ways to play beyond the sandbox like ActiveX/COM, GWT, even java applets or Google's Native Client are just some of the many ways to get to native code from a browser, depending on your needs or flavor.
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 9 years ago.
Improve this question
There are a lot of features and abilities of javascript that I am unaware of. I have developed a custom closed source CMS and I was thinking about adding a feature to allow for custom javascript that gets included on each page of their site (but not the backend system itself). I was curious of the risk involved with doing this? The CMS is built using PHP and there is javascript within the backend system of this CMS, but thats pretty much it.
If I allow custom javascript, can this be manipulated to retrieve all the php code, or to cause issues on the server itself?
I own the servers, so I can make any adjustments necessarily for safeguarding the server.
Again, this is purely for information and I appreciate any advice people can give me.
The javascript will be stored in a file and included using php on the page itself. I do have code that blocks anything inside to prevent the use of PHP within the code itself.
Can they steal my closed-source PHP code with JavaScript?
To answer your first question, no, your closed-source PHP code cannot be stolen by a user of your CMS software simply by uploading a JavaScript snippet.
This is because JavaScript runs on the client-side (the web browser).
If JavaScript is able to access your PHP code from the client-side, then they'd be able to access it without JavaScript. That would mean that you've configured something wrong on the web server side, like setting permissions on your files so that anyone can view them.
Is allowing JavaScript to be uploaded by a CMS user a good idea?
You'll get some folks who will scream ABSOLUTELY NOT UNDER ANY CIRCUMSTANCE. These are the same people who say things like:
Using eval() is always evil. It's not always evil, but it's almost always unnecessary.
Using global or $_GLOBALS in PHP is evil. Again, it's only evil if you don't know what you are doing. And again, it's almost always unnecessary.
You should read that as a WARNING. Don't treat this issue lightly, if you are careful, you can do it, but if you are not, it can really bite you in the a**. That's reason enough for most people to stay away from it.
Before you decide for sure if you should or shouldn't allow users of your CMS solution to upload JavaScript snippets, you should ask yourself the following question:
Who will be allowed to upload JavaScript snippets?
If the only people who have access to this feature of uploading JavaScript modules are trusted system administrators, then you should consider it safe. I put that in italics because it's not really safe, but it does, at that point, fall on these trusted users to ensure that they don't upload something malicious.
Maybe you get Mary Neophyte, webmaster(amateur) extraordinaire who decides she wants a cool scriptlet on her CMS front page that displays the current weather in Anchorage, Alaska. She goes to Google, types in "JavaScript weather script", and arrives at Weather Channel. She decides their implementation is just too hard to install. She keeps looking. She arrives at Boris' Weather Script at http:/motherrussia.ru/ilovehackingidiots/weatherscript.html.
This isn't your fault when her CMS starts compromising her end users. She was the trusted administrator who uploaded a malicious script purposefully (though ignorantly). You shouldn't be held responsible for this type of behavior.
Long story short, you should be able to trust the trusted users of your CMS to be responsible enough to know what they are uploading. If they shoot themselves in the foot, that's not on you.
Allowing non-trusted users to upload JavaScript
This absolutely, positively, without a doubt is never something that you should do. It is impossible for you to screen every possible obfuscation that someone could upload.
I'm not even going to get into this further. Don't do it. Period.
Regarding HTML/CSS
Don't assume that malicious code can't make it onto your website via HTML/CSS. While HTML is much easier to sanitize than JavaScript, it can still be exploited to deliver undesired JavaScript to a page.
If you are only allowing trusted users to upload HTML/CSS, then don't worry too much about it. I stress again, It is Mary Neophyte's fault if she uploads Boris' Weather Script to her site. However, don't let Boris himself come to your website and start uploading anything that will get displayed on a web page to anyone but ol' Boris himself.
TL;DR
I'll summarize everything into two rules:
Don't allow untrusted users to upload anything that will be displayed to anyone other than themselves.
Don't let anyone upload anything at all that gets executed server-side.
Allowing custom JavaScript would probably be a very bad idea. That would make your site vulnerable to cross-site scripting attacks and allow it to be a vector for cross-site request forgery attacks against other sites.
I am thinking about creating mini-games in JavaScript that a public social website (yourworldoftext.com) and I had a thought, I am a user of the site and would be embedding my JavaScript in a link's href that others can click on to start the game.
One way I was thinking about would be something like this
Compress/obfuscate the JavaScript as much as possible
Encrypt the JavaScript into a sctring and wrap everything with a small decryption JavaScript that will evaluate the decrypted string (the key to decrypt would be retrieved using AJAX from some other page on the same site)
Here is my motivation:
people should all be using the same version of the game and its not trivial to cheat
The source code contains hacks that might be easy for a JavaScript developer like me to write, but potentially the code could be copy pasted and misused to spam the site
The informed spammer could find any number of scripts already available for free online, I just don't want it to be free from my scripts
I want anyone to be able to run the app without any hidden secret to know (which would make having the script publicly available meaningless because then I'd just share the game those I trusted making the script itself the secret)
Don't misunderstand me, I know there is absolutely no way to ensure that the source code behind the JavaScript would not be available to the informed/intelligent user, I am merely polling to see if this is an exercise in futility and I shouldn't even bother with the extra encryption step, or if any believe that there is some merit to this technique.
I am inclined to believe that it might thwart the casual user, I'm just not sure how much knowledge would be required to break it, if maybe the casual social network user could break it.
Also, I suspect that firebug, developer tools, web inspector will just show the evaluated code anyway, but I'm not sure. If so then it wouldn't really do anything at all to protect it. Most users on the site use chrome (from what I hear because it works best on that browser). So would chrome show it easily in the web inspector?
Minification and obfuscation and encryption as you've described are all minor obstacles in the way of people mucking with your code. Each minor obstacle will discourage a small number of would-be hackers. But, none of the three will discourage the determined hacker.
All one has to do to get around the encryption is set a breakpoint in the debugger and capture the code right after it's been decrypted before it's sent to eval and then copy/paste out of the debugger. So, it barely even slows down the determined hacker. In fact, minification (replacing all meaningful variable names with meaningless short names actually creates more work for the hacker in understandong your code).
Personally, I'd avoid the encryption as it doesn't really add much and it's real easy for the determined hacker to get around.
You're right, this is futile. Don't bother with this at all. Your code, although minified and obfuscated can be lifted by users with little knowledge.
Now that JavaScript libraries like jQuery are more popular than ever, .js files are starting to contain more and more of a site's logic. How and where it pulls data/information from, how that info is processed, etc. This isn't necessarily a bad thing, but I'm wondering to what extend this might be a security concern.
Of course the real processing of data still happens in the backend using PHP or some other language, and it is key that you make sure that nothing unwanted happens at that point. But just by looking at the .js of a site (that relies heavily on e.g. jQuery), it'll tell a person maybe more than you, as a developer, would like. Especially since every browser nowadays comes with a fairly extensive web developer environment or add-on. Even for a novice manipulating the DOM isn't that big of a deal anymore. And once you figure out what code there is, and how you might be able to influence it by editing the DOM, the 'fun' starts.
So my main concerns are:
I don't want everyone to be able to look at a .js file and see exactly (or rather: for a large part) how my site, web app or CMS works — what is there, what it does, how it does it, etc.
I'm worried that by 'unveiling' this information, people who are a lot smarter than I am figure out a way to manipulate the DOM in order to influence JavaScript functions they now know the site uses, possibly bypassing backend checks that I implemented (and thus wrongly assuming they were good enough).
I already use different .js files for different parts of e.g. a web app. But there's always stuff that has to be globally available, and sometimes this contains more than I'd like to be public. And since it's all "out there", who's to say they can't find those other files anyway.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
What are your thoughts about this? Am I overreacting? Should I split my JS as much as possible or just spend more time triple checking (backend) scripts and including more checks to prevent harm-doing? Or are there some best-practices to limit the exposure of JavaScripts and all the info they contain?
Nothing in your JavaScript should be a security risk, if you've set things up right. Attempting to access an AJAX endpoint one finds in a JavaScript file should check the user's permissions and fail if they don't have the right ones.
Having someone view your JavaScript is only a security risk if you're doing something broken like having calls to something like /ajax/secret_endpoint_that_requires_no_authentication.php, in which case your issue isn't insecure JavaScript, it's insecure code.
I sometimes see a huge chuck of JavaScript without line breaks and all that. Like the compact jQuery files. I'm sure there are applications or tricks to convert your normal .js file to one long string. But if it can do that, isn't it just as easy to turn it back to something more readable (making it pointless except for saving space)?
This is generally minification (to reduce bandwidth usage), not obfuscation. It is easily reversible. There are obfuscation techniques that'll make all variable and function names something useless like "aa", "bb", etc., but they're reversible with enough effort.
Lastly I was thinking about whether it was possible to detect if a request for a .js file comes from the site itself (by including the script in the HTML), instead of a direct download. Maybe by blocking the latter using e.g. Apache's ModRewrite, it's possible to use a .js file in the HTML, but when someone tries to access it, it's blocked.
It's possible to do this, but it's easily worked around by any half-competent attacker. Bottom line: nothing you send a non-privileged user's browser should ever be sensitive data.
Of course you should spend more time checking back-end scripts. You have to approach the security problem as if the attacker is one of the key developers on your site, somebody who knows exactly how everything works. Every single URL in your site that does something to your database has to be protected to make sure that every parameter is within allowed constraints: a user can only change their own data, can only make changes within legal ranges, can only change things in a state that allows changes, etc etc etc. None of that has anything at all to do with what your Javascript looks like or whether or not anyone can read it, and jQuery has nothing at all to do with the problem (unless you've done it all wrong).
Remember: an HTTP request to your site can come from anywhere and be initiated by any piece of software in the universe. You have no control over that, and nothing you do to place restrictions on what clients can load what pages will have any effect on that. Don't bother with "REFERER" checks because the values can be faked. Don't rely on data scrubbing routines in your Javascript because those can be bypassed.
Well, you're right to be thinking about this stuff. It's a non-trivial and much misunderstood area of web application development.
In my opinion, the answer is that yes it can create more security issues, simply because (as you point out) the vectors for attack are increased. Fundamentally not much changes from a traditional (non JS) web application and the same best practises and approaches will server you very well. Eg, watching out for SQL injection, buffer overflows, response splitting, etc... You just have more places you need to watch out for it.
In terms of the scripts themselves, the issues around cross-domain security are probably the most prevalent. Research and learn how to avoid XSS attacks in particular, and also CSRF attacks.
JavaScript obfuscation is not typically carried out for security reasons, and you're right that it can be fairly easily reverse engineered. People do it, partially to protect intellectual property, but mainly to make the code download weight smaller.
I'd recommend Christopher Wells book published by O'Reilly called 'Securing Ajax Applications'.
There is free software that does JavaScript Obfuscation. Although there is not security though obscurity. This does not prevent all attacks against your system. It does make it more difficult, but not impossible for other people to rip off your JavaScript and use it.
There is also the issue of client side trust. By having a lot of logic on the client side the client is given the power to choose what it wants to execute. For instance if you are escaping quote marks in JavaScript to protect against SQL Injection. A Hacker is going to write exploit code to build his own HTTP request bypassing the escaping routines altogether.
TamperData and FireBug are commonly used by hackers to gain a deeper understanding of a Web Application.
JavaScript code alone CAN have vulnerabilities in it. A good example is DOM Based XSS. Although I admit this is not a very common type of XSS.
Here's a book by Billy Hoffman about Ajax security:
http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1266538410&sr=1-1