I'm looking for a simple method of encrypting a small portion of my personal developer website. I'd like to display my resume directly on the site, but would prefer to protect it with a password so as to prevent those who are not potential employers from viewing it. What is a safe way of doing so while imposing a limited strain on potential employers (e.g. not requiring them to create an account)?
Notably, I will not be including information like my SSN or anything particularly sensitive -- just regular resume info. For this reason, would it be okay to provide all potential employers with the key, and rotating it every month-or-so?
I'm using Lit as a web component tool, but otherwise the site is vanilla JS + html.
Thanks for any guidance!
Some shared hosting providers offer password protection as part of their package. You could contact your host and see if that's an option.
Otherwise the simplest password protection solution which doesn't require any third party tools would be to update your .htaccess file to require a password. See this question for examples on setting it up.
Please note, that this should not be considered a completely secure solution, because it's only basic authentication which can be vulnerable to brute force attacks. However it should satisfy your requirement of adding some protection your personal information.
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.
I am building a 3rd party widget
We drop a script on a clients page and load some content.
The problem I face is how do I secure my widget. As a thrid party widget I know there is no 100% way to secure it. But trying to work out a 'good enough' approach.
I want to make it difficult for a non customer to just rip our script off their competitor site and use it on theirs.
The solutions I see is pull validate requesting domain (which I know could be spoofed, not sure if I can guard against this?)
I had a look at other widgets like olark and olapic that use unique id's per client in their script , but cannot see how helpful that is.
What are the best practices to secure a third party widget?
Securing a tenant's client access
Securing a tenant's 3rd party client access to your Javascript poses a unique set of challenges. Most of the difficulty in this solution stems from the fact that the authentication mechanism must be present in the tenants web content and delivered from their clients browser. Standard client<>server authentication mechanisms such as sessions, cookies, custom headers, referrers and IP address restriction do not apply well due to the extended nature of the transaction.
This article by Bill Patrianakos provides a solution by using a dynamic key request that provides an access token to the tenant's client.
Patrianakos provides some good information on Third Party tenant relationships and discusses some the limitations of this model in his article.
Securing the Javascript code
Protecting your code in Javascript is difficult due to the requirement that the code is interpreted at runtime by the client browser. However, it is possible to obfuscate your Javascript by using the Google Closure Compiler. The advanced optimization features of the compiler offer low-level reference renaming and also provides more compact code for delivery of your widget.
To compile your Javascript using advanced optimizations use the following command line:
java -jar compiler.jar --compilation_level ADVANCED_OPTIMIZATIONS \
--js myWidget.js --js_output_file myWidget.min.js
There are some important caveats. This article covers some of the things to avoid in your code to ensure that the code will function correctly. I would also recommend a good qunit test frame to ensure that your widget will operate properly.
To secure the widget, if you want to prevent forged requests then you need to open a popup and open a page from your server which is completely under your control, and confirm any actions such as 'publish tweet' there.
See the answer for this question for some more extended discussion.
For preventing your Javascript from being stolen, minification is not sufficient - it's better to use an obfuscator. Have a look for example [JScramble], this is a presentation on how it works.
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.
I've got a marketing team that wants social sharing buttons (Facebook, G+, SU, and so forth) on our site. The security team brought up a point that I'm embarrassed to admit I hadn't really considered before: since 3rd-party JS is an attack vector, we shouldn't load it directly off the third party servers.
The risk
I'll use Facebook as the example. Someone at FB could add some sneaky backdoor code to watch users or at very least grab their email & name from our site. DNS cache poisoning could be used to serve malicious Javascript instead of the expected FB library. Etc - there are probably many more attack vectors here.
Possible solutions
-Host the JS locally (after vetting it for security holes), and run curl+diff on cron to watch for updates -- vetting those updates before hosting. This isn't really viable because FB and g+ both load additional libraries offsite after their primary lib is loaded, and I haven't found a way around that.
-Don't use social sharing buttons?
Is there an accepted best practice here? My first reaction is that, come on, this is Google and Facebook. If something malicious happens to their social sharing buttons, the entire Internet is going to know about it in 0.001 seconds. What say you?
There really isn't any generally accepted solution for this besides either:
Blindly trust Facebook / Google / etc.
Don't use their scripts.
If you load all of the libraries (and all of your site) on SSL, you are only vulnerable to malicious behavior within Facebook / Google.
You can either trust them, or don't use the libraries and do it yourself using publicly documented URLs or their server-side APIs.
Lets be realistic here. While I know anything can happen, it is much more likely that your site will get hacked than Google/Facebook/Twitter injecting malicious code into your site through a disgruntled employee or something similar. It could happen, but chances are pretty slim.
If the client visiting your site's DNS is compromised, then injecting their own facebook.com A-Record so they can inject javascript into your site is the least of your worries. If I were running a malicious DNS server and had people using it; and I had malicious intent, I'd either be targeting your site specifically and I'd just make a site that looks like yours and takes all user data into my database; or I'd be after banks and financial institutions. Injecting facebook javascripts would not be my primary objective.
Again, it could happen, but in my mind, there are way too many other, lower hanging fruit to make it worth really worrying about. If you have some government regulation that makes you responsible for this type of thing, it might be wise to play it on the safer side and just not use them, or implement your own "like" buttons using the facebook APIs. I'm sure G+ and Twitter have similar non-javascript based ways to do this.
We are going to design and implement a UI for a big website. Owner of the site is really cautious about security issues. I wonder if there is a check list for client-side security recommendations, when designing and coding in Javascript.
You may use the OWASP guide as a start. It offers a suite of tests that you can systematically use to check your application for common vulnerabilities.
Web application pen testing is a buzz word for what you are trying to achieve. Scan the net for automated tools and background information.
Edit:
You mentioned that not only the client side is your concern, but the overall security of the entire application including the server. My advice would be that if you have never done security assessment of an application before, your boss/the owner of the site should probably consider hiring an external company/consultant for the job. They will do the job for less than it would probably cost if you and your team had to learn the details first. Plus, they have the advantage of having this done over and over again, so they are much less likely to overlook important details.
Javascript can easily be tricked. You need to build a system with server side has all the security and the client side will only acts as a interface similar to browser.
Encrypting using strong security certificate will also be an option you may consider.