Internet Security
The following solution is for Windows computers.
1. Access your Local Disk (C:) – also called Windows (C:). Look for the host file in the etc file in the drivers folder. C:\Windows\System32\drivers\etc
2. Open the host.txt, and at the very end, under the 127.0.0.1 localhost configuration, add: “127.0.0.1 www.websiteYouWantToBlock.xx”.
Additional websites can be added on a next line
3. Save changes
This process blocks the desired webpages from any browser.
Taggings:
act carefully :)
-) Verify data is encrypted
When sending confidential information over the Internet such as usernames, passwords, or credit card numbers only send it securely (i.e. via SSL-encryption). To verify this, newer browsers indicate a correct encryption with a green address bar in the browserwindow.
Also make sure, the URL begins with https://
If a webpage is not secure, such as an online forum, use a password you wouldn't use with protected sites such as your online banking website.
-) E-mail is not encrypted
E-mail (per default) is not encrypted and if intercepted by a third-party could be easily read.
-) Be aware of phishing scams
Familiarized yourself with phishing scams and techniques, which are used to trick you into divulging your account information. Online banking sites, Paypal, EBay, Amazon, and other popular sites that require logins are popular targets.
-) Use a safe password
Websites that store confidential data, such as an online bank site need to use strong passwords. Also, it is highly recommended that you use a different password for each website that requires a login.
-) Use caution when accepting or agreeing to prompts
When prompted to install any program or add-on make sure to read and understand the agreement before clicking on the Ok button. If you do not understand the agreement or feel it is not necessary to install the program cancel or close the window.
Additionally, when installing any program watch for any check box that asks if it's ok to install a third-party program, toolbar, etc. These are never required and often cause more issues than good. Leave these boxes unchecked.
-) Be aware of those around you
While at work, university, library, or anywhere that has people around who could look at the monitor be cautious of anyone shoulder surfing. Someone could watch you type in your password, which would give them access to your account.
-) Update browser plugins
Often many attackers find security vulnerabilities through browser plugins. Make sure all installed Internet plug-ins are up-to-date.
Secure Web-Application
Within the framework of the procurement of Web application substantial security holes were evident (recognized by by examinations/ (IT-Securtiy checks).
The Web applications are ordered by the company at different suppliers, who carry out the software development. In the course of the agency, however, there is no further specification concerning the requirement to IT-regarding to an implicit approach „it just must be safe “.
These facts cause the following problems:
+ The level of IT-Security is not defined and depends on the
provider
+ The frame of vunerabilities found by security-checks cannot be
regarded as lacks, no specification is available.
+ The repair of vunerabilties depends on the goodwill of the
providers
+ If clients-data are run at this Website, the data protection is
not guaranteed.
Taggings:
Encoded Password submission
The basic idea in this approach is to encode the password before sending it, no matter in which direction. Therefore we could be sure that the plain password cannot be read without breaking the encoding before. While this approach has some merit, it is only really effective in reality when the encoding is either hard, lossy or both as with an encoding that is neither, a rule may be found to extract the original password again.
On the other hand, sending a password that went through such treatment to the user, it would/should be impossible for the user to find out if this password is really his or not. All web services that provide a reminder function where the stored password is sent to the user, and this password is, above all, in plain text too, may not be considered secure at all.
For this reason such reminder functions can only work with additional information (e.g. “whats the name of your first pet?”) provided by the user that was agreed upon earlier.
So to ensure the privacy of the password through its whole lifecycle is hard and needs some adjustments to otherwise accepted behavior, on the side of the users as well as the system.
The password must be generated by the user, it is then encoded locally with a lossy method and transferred over a secure connection (ssh,…) to the server where the password will be stored in a lossy state. All further compares base on the user sending a lossy encoded password and the server side controlling it.
Password delivery problem
When handling sensible information in the internet it has become common to verify users by a combination of password and username. More often than not the first communication between a web service and a new user is the registration. Therefore this point of exchange is quite vulnerable for many kind of attacks (man-in-the-middle, spoofing, knock-back,..), mostly with the goal to fetch the registration data for a third party.
The first step towards countering such methods is to establish a somewhat secure channel before requesting any detailed data from the user, but passwords must be verified and for that they have to be transmitted. Besides https and ssh there are many other protocols that increase the overall security, but still submitting passwords in plain is not an option for various reasons.
What is the best way to establish a secure handshake between webservices and users? or how can they both agree on one password without the need to sent it?
Taggings:
Preventing SQL-Injection in a Java application
Sql-Injection is a technique to inject (or execute) SQL commands within an application (database). It is mainly used to gain access to a databases content for which one has no authorization. The method injects SQL commands by providing input to a SQL statement which contains SQL meta-characters.
Example statement: <strong>select * from user where username='input'</strong>
SQL injected input:<strong>user' OR '1'='1</strong>
The final statement:<strong>select * from user where username='user' OR '1'='1'</strong>
Since 1 always equals 1, this statement would return all the users in the database!
Depending on the SQL command, an attacker could insert, modify, extract and delete data in the database.
Connecting an Authentication Server to a Drupal Content Management System
For my Ph.D. thesis I need a community portal, which supports students to share their experience about internet technologies. It turned out, that the content management system Drupal is a perfect fit to fullfill the given requirements. As usual for a content management system, Drupal also has its own user management function. This means, that students have to register before they may produce content on the portal. Although TechScreen is a software system on a prototype level, it is yet hosted on a server inside the TU computer network. Therefore it is expected to provide a login procedure, which makes use of the students TU credentials. So the big question is, how to connect the TechScreen system to the TU authentication server.
Taggings:
